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1.  OIS  EXECUTIVE  SUMMARY 

The  Operational  Information  System  project  is  a  proof  of  concept  effort  developed  at  the  request 
of  the  Office  of  Command,  Control,  and  Communications  (G-T).  In  their  Request  for  R&D 
Support,  G-T  directed  the  Research  and  Development  Center  to  examine  ways  to  improve  the 
information  flow  in  Coast  Guard  operations.  The  project  examined  information  systems,  using  a 
business  reengineering  methodology  in  order  to  understand  and  improve  the  total  work  systems  in 
field  operations. 

The  Operational  Information  System  core  concept  is  to  “Improve  service  to  the  maritime  public 
by  getting  the  right  operational  information  to  the  right  people  at  the  right  time  to  make  the  right 
decision.”  This  implies  a  highly  cross-fiinctional  system,  covering  most  missions  of  the  Coast 
Guard.  OIS  is  a  clear  embodiment  of  the  “One  Port,  One  Command  Center”  principle  espoused 
by  former  Commandant  ADM  J.W.  Kime.  It  also  supports  the  current  Commandant’s  Eighth 
Strategic  Goal,  to  “pursue  and  acquire  new  technologies  that  meet  field  commanders’  needs  and 
enhance  mission  performance.” 


1.1  Problem  Statement 

The  problems  described  in  this  report  have  been  identified  by  a  variety  of  studies,  both  internal 

and  external  to  the  Coast  Guard.  The  OIS  testbed  addressed  only  a  selected  subset  of  these 

problems,  either  in  the  technical  high  risk  category  or  in  the  business  process  redesign  category. 

1.  Redundant  Data  Entry.  The  Coast  Guard’s  present-generation  information  systems  are 
characterized  by  a  great  deal  of  redundant  data  entry. 

2.  Information  not  available  to  Field  Personnel  Many  current  Coast  Guard  information 
systems  are  designed  primarily  to  provide  information  to  program  managers.  In  several  cases, 
this  information  is  not  available  to  field  personnel  later. 

3.  Inadequate  Communications.  The  Coast  Guard’s  existing  communications  systems  are 
characterized  by  most  studies  as  inadequate. 

4.  Inadequate  Resource  Picture.  The  resource  picture  is  typified  by  command  centers  that  have 
wall  charts  of  their  operating  area  with  magnetic  shapes  of  cutters,  aircraft,  and  boats. 

5.  Cumbersome  Tasking  Process.  Providing  tasking  to  resources  is  frequently  cumbersome  in 
today’s  Coast  Guard. 

6.  '‘Stovepipe*'  Information  Systems.  The  Coast  Guard’s  operating  platforms  and  its  personnel 
are  multi-mission,  but  our  information  systems  have  not  yet  achieved  that  maturity.  Instead, 
they  are  predominantly  single-mission  “stovepipes.” 
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7.  Proliferation  of  Systems.  Because  of  the  lack  of  cross-functional  systems.  Coast  Guard 
command  centers  house  an  ever-increasing  variety  of  information  systems  that  do  not 
communicate  with  one  another. 

8.  Multi-level  Security.  The  Coast  Guard  arguably  has  a  larger  problem  with  separation  of 
classified  and  unclassified  information  than  any  other  agency. 

1.2  Operational  Information  System  Goals 

Analysis  of  the  problem  statements  reveals  that  there  are  several  common  mission  performance 
and  workload  impacts  that  result  from  these  problems.  The  following  three  Operational 
Information  System  goals  have  been  developed  through  analysis  of  the  common  elements 
impacting  mission  performance. 

f  Improve  command  and  control  (problems  3, 4, 5, 6, 7, 8). 

#  Eliminate  redundancy  of  reports  (problems  1, 6, 7). 

#  Improve  availability  of  information  to  field  personnel  (problems  2, 3, 6, 7, 8). 

1.3  Project  Approach 

The  R&D  Center  split  OIS  into  two  phases,  with  the  possibility  of  others  in  the  future.  Each 
phase  began  with  a  series  of  in-depth  user  workshops  involving  operational  personnel  from 
around  the  country.  They  focused  on  (a)  defining  information-related  problems  in  current 
operations,  (b)  defining  a  set  of  solutions  to  those  problems,  and  (c)  describing  the  payoffs 
(benefits)  anticipated.  Based  on  the  results  of  these  workshops,  the  R&D  Center  developed 
proof-of-concept  systems  to  evaluate  the  feasibility  of  implementing  the  ideas.  The  systems  were 
installed  in  an  actual  operational  environment  for  several  months  in  order  to  validate  and  refine 
the  functional  requirements  developed  during  the  workshops,  and  subject  the  system  concepts  to 
the  harsh  light  of  real-world  usage. 

1.4  BENEFITS  Summary 

Empirical  data  collected  during  the  Group/Station  OIS  Testbed  focused  primarily  on  reports 
reduction.  While  there  are  measurable  benefits  from  this  feature,  they  are  not  large  and  are  also 
not  capturable.  The  consensus  of  the  Group  Commander  and  senior  officers  who  visited  was  that 
the  major  benefits  OIS  could  provide  the  Coast  Guard  are  a  result  of  improved  resource 
utilization.  Information  would  become  a  force  multiplier,  allowing  better  coordination  of  multi¬ 
unit  operations.  Operational  commanders  could  leverage  their  assets  to  greater  advantage, 
especially  if  OIS  were  combined  with  innovative  crewing  concepts  such  as  the  Norwegian 
Crewing  Concept.  This  would  enable  business  process  reengineering  such  as  more  centralized 
command  and  control,  and  more  centralized  resource  basing.  The  resulting  organization  would 
include  less  shoreside  infrastructure,  fewer  coordination  personnel.  It  would  also  enable  covering 
the  same  areas  with  fewer  assets. 
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1.5  Conclusions 

It  appears  technically  feasible  for  the  Coast  Guard  to  implement  the  Operational  Information 
System.  Most  underlying  technologies  are  well  developed,  with  none  posing  unacceptable 
technical  risk.  The  three  highest  risk  technological  areas  in  a  full-scale  deployment  are  distributed 
database  technology,  satellite  communications,  and  pen-based  computing.  Further,  information 
technology  has  matured  to  the  point  that  the  Coast  Guard  can  now  implement  the  Operational 
Information  System  cost-effectively. 

The  Operational  Information  System  is  a  critical  enabler  for  the  One  Port/One  Command  Center 
concept.  In  order  to  consolidate  functions  physically,  they  must  be  consolidated  logically.  If  the 
Coast  Guard  simply  houses  the  same  business  fiinctions  in  a  single  room  without  changing  their 
component  work  processes,  the  total  workload  will  remain  unchanged,  and  the  same  level  of  staff 
will  be  required  to  support  them.  OIS  provides  the  cross-functional  information  infrastructure 
necessary  to  complete  the  logical  consolidation. 

OIS  will  increase  operational  commanders’  span  of  control  and  act  as  a  force  multiplier,  allowing 
the  agency  to  perform  assigned  missions  with  fewer  resources.  This  enables  organizational 
flattening,  with  less  District/Group  Commands.  Combining  OIS  with  the  introduction  of 
improved  boats  and  aircraft  will  enable  the  Coast  Guard  to  operate  with  fewer  resources  in  the 
field.  This  is  an  important  enabler  in  meeting  the  Commandant’s  third  strategic  goal;  “meet  the 
mandate  to  streamline  with  no  reduction  in  essential  services.” 

Redundant  data  entry  can  be  virtually  eliminated.  Automatic  transfer  of  information  from  OIS  to 
legacy  systems  such  as  SARMIS  and  LEIS  II  is  a  significant  time  saver,  allowing  greater  focus  on 
operations.  This  will  also  improve  the  work-life  balance  for  Coast  Guard  people. 

Embedding  decision  support  functionality  within  OIS  can  improve  the  quality  of  decision  making 
at  all  levels  of  the  chain  of  command.  It  can  also  eliminate  the  need  for  extensive  resident  training 
on  calculation  and  rule-based  tasks.  Training  can  focus  on  educating  the  person  about  the 
rationale  behind  performing  tasks,  but  does  not  need  to  cover  implementation  details.  This  is 
especially  valuable  for  tasks  which  are  performed  infrequently  but  are  procedure-intensive.  It  also 
allows  program  managers  to  update  policies  and  procedures  easily  by  updating  the  decision 
support  system. 

OIS  provides  a  tool  for  improved  measurement  of  our  operational  services,  and  therefore  better 
management  of  the  resources.  Capturing  employment  data  as  a  byproduct  of  operations  will 
increase  accuracy  and  decrease  workload. 

1.6  Recommendations 

Based  on  the  results  of  the  Group/Station  Operational  Information  System  Testbed,  the  Research 
and  Development  Center  recommends  the  following. 
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That  the  Coast  Guard  undertake  development  of  the  Operational  Information  System.  Appendix 
C  contains  a  preliminary  fiinctional  decomposition  of  the  Phase  I  and  II  Research  and 
Development  testbed  systems,  which  integrate  Search  and  Rescue  and  Law  Enforcement. 

That  the  Coast  Guard  use  the  Operational  Information  System  as  a  framework  to  integrate  other 
major  systems  already  in  development.  These  include  the  Marine  Safety  Network  and  the  Vessel 
Traffic  System  2000.  In  addition  to  these  major  acquisitions,  the  Coast  Guard  has  a  substantial 
investment  in  the  Navy’s  Joint  Maritime  Command  Information  System  (JMCIS),  or  some  of  its 
variants.  Both  major  cutters  and  major  command  centers  ashore  are  currently  users  of  these 
systems  This  item  will  require  that  OIS  exploit  multi-level  security  technology. 

That  the  Coast  Guard  implement  the  alternative  in  the  Short  Range  Communications  System 
proposals  which  includes  the  most  capable  data  transfer  capabilities,  including  secure  data 

transmission. 

That  the  Coast  Guard  implement  a  long  range  data  communications  system  as  part  of  an  overall 
communications  architecture  designed  to  extend  the  existing  shore-based  wide  area  network  to  its 
operating  resources. 

That  further  research  be  done  on  human  factors  issues  surrounding  use  of  portable  computers 
during  boardings.  The  potential  exists  to  improve  the  boarding  process,  but  the  results  of  the 
Group/Station  Testbed  were  negative  toward  use  of  portable  computers.  This  was  clearly  due  in 
large  part  to  technical  flaws  in  the  testbed  system,  but  there  remained  a  large  unwillingness  to 
commit  to  use  of  computers  during  boardings.  The  primary  concern  is  that  computers  would 
require  too  much  attention,  detracting  from  the  boarding  party’s  situational  awareness  and  safety. 
Unless  further  research  indicates  with  a  high  degree  of  probability  that  design  improvements  can 
eliminate  the  concern  about  situational  awareness,  we  recommend  against  implementation  of 
portable  computers  during  boardings. 
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2.  INTRODUCTION 

The  Operational  Information  System  project  is  a  proof  of  concept  effort  developed  at  the  request 
of  the  Office  of  Command,  Control,  and  Communications  (G-T).  In  their  Request  for  R«&D 
Support,  G-T  directed  the  Research  and  Development  Center  to  examine  ways  to  improve  the 
information  flow  in  Coast  Guard  operations.  The  project  examined  information  systems,  using  a 
business  reengineering  methodology  in  order  to  understand  and  improve  the  total  work  systems  in 
field  operations. 

The  Operational  Information  System  core  concept  is  to  “Improve  service  to  the  maritime  public 
by  getting  the  right  operational  information  to  the  right  people  at  the  right  time  to  make  the  right 
decision.”  This  implies  a  highly  cross-functional  system,  covering  most  missions  of  the  Coast 
Guard.  OIS  is  a  clear  embodiment  of  the  “One  Port,  One  Command  Center”  principle  espoused 
by  former  Commandant  ADM  J.W.  Kime.  It  also  supports  the  current  Commandant’s  Eighth 
Strategic  Goal,  to  “pursue  and  acquire  new  technologies  that  meet  field  commanders’  needs  and 
enhance  mission  performance.” 


2.1  Problem  Statement 

The  problems  described  in  this  report  have  been  identified  by  a  variety  of  studies.  These  include  a 
GAO  report  of  April  1990  entitled  “COAST  GUARD:  Strategic  Focus  Needed  to  Improve 
Information  Resources  Management”;  the  Coast  Guard’s  Strategic  Information  Resource 
Planning  process  (SIRMP);  the  Small  Boat  Station  Staffing  Study  of  July  1991;  the  Group 
Staffing  Study  of  February  1991;  and  the  Command  Center  Study  of  October  1991.  The  first  five 
problems  are  stated  in  the  form  described  by  a  group  of  field  personnel  during  a  series  of  intensive 
workshops  (see  Project  Approach  for  details).  The  sixth  is  from  the  SIRMP  process.  The 
seventh  is  from  the  Command  Center  Study. 

The  OIS  testbed  addressed  only  a  selected  subset  of  these  problems,  either  in  the  technical  high 
risk  category  or  in  the  business  process  redesign  category.  However,  the  OIS  concept  is  to 
empower  the  Coast  Guard’s  field  personnel  by  solving  each  of  these  problems,  or  by  integrating 
other  Coast  Guard  systems  that  solve  parts  of  them. 

1.  Redundant  Data  Entry.  The  Coast  Guard’s  present-generation  information  systems  are 
characterized  by  a  great  deal  of  redundant  data  entry.  There  are  several  layers  to  this 
problem.  First,  most  systems  support  a  single  mission,  and  only  a  single  aspect  of  that 
mission.  Second,  most  systems  do  not  support  operations  while  they  are  in  progress.  Instead, 
they  are  primarily  oriented  to  after-the-fact  reporting  for  post-mission  analysis.  As  a  result, 
users  frequently  have  to  document  a  case  in  three  stages,  in  three  or  more  systems.  They  take 
handwritten  notes  during  operations.  They  write  record  message  Situation  Reports,  which  are 
basically  narrative  summaries  transcribed  from  their  notes,  at  intervals  of  a  few  hours  during 
operations.  Finally,  they  enter  summary  information  into  various  information  systems  after  the 
operations  are  complete.  The  human  watchstanders  in  command  centers  and  aboard  operating 
resources  spend  a  substantial  amount  of  their  time  processing  information  at  a  low  level,  such 
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as  recording  it  and  transcribing  it.  However,  what  they  really  need  to  do  is  analyze  the 
information,  and  make  decisions  or  take  action  based  upon  that  analysis. 

2.  Information  not  available  to  Field  Personnel  Many  current  Coast  Guard  information 
systems  are  designed  primarily  to  provide  information  to  program  managers.  In  several  cases, 
this  information  is  not  available  to  field  personnel  later.  When  it  is  available,  the  process  for 
retrieving  it  is  frequently  so  difficult  that  field  personnel  don’t  bother.  Field  personnel  are 
doubly  fhistrated  by  this.  They  know  that  the  information  they  are  entering  could  be  useful  to 
them  at  a  later  date.  But  they  also  know  that  it  will  be  difficult  or  impossible  to  retrieve  it. 
Therefore,  they  have  no  incentive  to  make  sure  that  it  is  accurate.  They  need  the  ability  to 
easily  retrieve  information  on  operations  previously  conducted  by  their  own  units  or  others. 

3  Inadequate  Communications.  The  Coast  Guard’s  existing  communications  systems  are 
characterized  by  most  users  as  inadequate.  The  communications  system  available  to  boats 
consists  of  VHF-FM  voice  radio  on  public  frequencies,  which  covers  the  majority  of  the 
coastline.  There  is  also  a  more  limited-range  “private”  (DES  encrypted  to  FOUO  level)  VHF- 
FM  voice  radio  system,  but  there  are  much  more  substantial  lapses  in  coverage.  Very  few 
locales  have  direction-finding  capability.  Data  capability  is  extremely  limited. 

4.  Inadequate  Resource  Picture.  Command  center  personnel  fi-equently  do  not  have  a  current 
picture  of  all  available  resources  and  their  status.  The  resource  picture  is  typified  by  command 
centers  that  have  wall  charts  of  their  operating  area  with  magnetic  shapes  of  cutters,  aircraft, 
and  boats.  These  shapes  are  moved  at  sporadic  intervals  by  controllers  after  voice  position 
reports  from  the  operating  units.  If  positions  are  not  current  when  notification  of  a  new  case 
is  received,  critical  time  is  spent  updating  the  resource  picture  before  selecting  resources. 

5.  Cumbersome  Tasking  Process.  Providing  tasking  to  resources  is  frequently  cumbersome  in 
today’s  Coast  Guard.  Detailed  search  plans  are  relayed  by  voice  communications  systems, 
with  humans  reading  and  transcribing  long  strings  of  numbers.  For  larger  units,  they  can  be 
sent  by  record  message,  but  the  watchstanders  at  each  end  have  to  pick  the  points  off  the 
chart  and  type  them  into  a  record  message,  and  invert  that  process  at  the  receiving  end.  This 
process  is  error-prone  and  laborious. 

6.  “Stovepipe”  Information  Systems.  The  Coast  Guard’s  operating  platforms  and  its  personnel 
are  multi-mission,  but  our  information  systems  have  not  yet  achieved  that  maturity.  Instead, 
they  are  predominantly  single-mission  “stovepipes.” 

7.  Proliferation  of  Systems.  Because  of  the  lack  of  cross-functional  systems.  Coast  Guard 
command  centers  house  an  ever-increasing  variety  of  information  systems  that  do  not 
communicate  with  one  another.  Each  has  different  user  interface,  training,  hardware,  and 
security  requirements.  Faced  with  a  proliferation  of  systems,  controllers  frequently  only  know 
how  to  use  portions  of  each.  Further,  when  information  must  get  from  one  to  the  other,  the 
controllers  wind  up  being  the  interface,  reading  from  one  system  and  retyping  into  the  other. 
Systems  present  in  many  of  the  Coast  Guard’s  District  and  Area  Command  Centers  include 
the  Coast  Guard  Standard  Workstation  for  administrative  use;  a  secure  Coast  Guard  Standard 
Workstation  for  classified  information  processing;  secure  Navy  Command  and  Control 
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systems  for  anti-drug  network  and  other  uses;  a  Coast  Guard  geographic  display  system  for 
search  planning  and  merchant  vessel  position  tracking;  Navy  computers  for  Maritime  Defense 
Zone  functions;  terminals  for  access  into  other  federal  agency  systems  such  as  the  Treasury 
Enforcement  Computer  System;  and  terminals  for  access  into  state  agency  systems  such  as  the 
National  Law  Enforcement  Telecommunications  System. 

8.  Multi-level  Security  The  Coast  Guard  arguably  has  a  larger  problem  with  separation  of 
classified  and  unclassified  information  than  any  other  agency.  Our  multi-mission  command 
centers  and  resources  may  find  themselves  handling  an  unclassified  search  and  rescue  or  oil 
pollution  case  one  minute,  followed  by  a  classified  law  Enforcement  or  National  Security 
incident  the  next.  Much  of  the  information  is  common  between  the  two,  such  as  resource 
positions  and  capabilities.  This  makes  it  extremely  important  for  the  Coast  Guard  to  develop 
a  robust  multi-level  security  capability  within  its  command  center  information  systems,  to  help 
authorized  personnel  integrate  the  classified  and  unclassified  pictures  while  simultaneously 
prohibiting  access  by  unauthorized  personnel. 

2.2  Operational  Information  System  Goals 

Analysis  of  the  problem  statements  reveals  that  there  are  several  common  mission  performance 
and  workload  impacts  that  result  from  these  problems.  The  following  three  Operational 
Information  System  goals  have  been  developed  through  analysis  of  the  common  elements 
impacting  mission  performance.  The  following  paragraphs  provide  detailed  explanations  of  the 
linkage  between  each  goal  and  the  related  problem  statements. 

#  Improve  command  and  control  (problems  3, 4, 5, 6, 7, 8). 

4  Eliminate  redundancy  of  reports  (problems  1, 6, 7). 

4  Improve  availability  of  information  to  field  personnel  (problems  2, 3, 6, 7, 8). 

Command  and  control  is  critically  dependent  on  rapid,  reliable  communications  (problem  3),  with 
appropriate  security  in  place  (problem  8).  These  are  needed  in  order  to  receive  notification  of 
situations  which  merit  action;  to  monitor  status  of  Coast  Guard  and  other  resources  (problem  4); 
and  to  transmit  action  orders  to  resources  (problem  5).  Voice  radio  provided  a  huge  advance  in 
communications  capability  from  the  pre-radio  era,  but  voice  communications  still  require  that  a 
human  act  be  directly  involved  in  the  act  of  communicating.  Computer-to-computer 
communications  eliminates  that  task.  Further,  system  designers  can  not  only  have  the  computer 
perform  the  communications,  but  manipulate  the  data  in  order  to  present  it  to  the  user  in  a  more 
readily  understandable  format.  Command  and  control  is  inherently  a  time-critical  task,  in  which 
seconds  can  make  the  difference  in  saving  a  life  or  intercepting  a  drug  smuggler.  The  segregation 
of  information  into  separate  systems  (problem  6)  and  the  time  required  to  retrieve  it  (problem  7) 
are  time  consuming  elements  in  an  environment  which  cannot  afford  extra  time. 

The  Coast  Guard  has  implemented  numerous  automated  systems  over  the  past  decade  in  order  to 
improve  information  availability.  These  systems  have  been  sponsored  by  different  program  and 
support  managers,  however,  and  significant  overlaps  exist.  This  proliferation  of  independent 
systems  (problems  6  and  7)  has  resulted  in  a  substantial  degree  of  redundancy  in  the  information 
entered  in  each  by  the  end  user  in  the  field  (problem  1). 
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Many  of  the  systems  the  Coast  Guard  has  implemented  are  designed  to  provide  information  for 
headquarters  use  by  program  planners.  Little  information  is  available  to  field  personnel,  or  the 
procedures  for  retrieving  it  are  cumbersome  (problem  2).  Coast  Guard  field  units  are  as  a  rule 
multi-mission,  or  cross-functional.  However,  information  is  fragmented  among  several  systems 
(problem  6),  and  therefore  field  personnel  must  access,  retrieve,  and  synthesize  information  from 
several  sources  in  order  to  respond  to  an  incident  which  crosses  program  boundaries.  This 
requires  significant  training,  effort,  and  precious  time  (problem  7).  If  some  of  the  information  is 
classified,  a  further  impediment  to  rapid  information  retrieval  is  encountered  (problem  8).  The 
data  conmunications  infrastructure  ashore  is  capable  of  providing  improved  access  to  information 
from  many  locations,  but  it  must  be  expanded  to  incorporate  afloat  units. 

2.3  Research  Objectives 

The  R&D  Center  was  tasked  by  the  OIS  Guidance  Team  to  investigate  critical  portions  of  the 
OIS  concept.  These  were: 

♦  Develop  a  concept  of  operations  for  field  operational  information 
dissemination  and  gathering,  and  test  technology  and  systems  approaches  that 
enable  that  concept. 

♦  Support  the  Station  Study  Implementation  Team  and  the  Command  Center 
Study  Team  in  their  efforts  to  improve  the  efficiency  and  effectiveness  of 
Station  and  Group  operations  by  providing  information  systems  and 
technology  that  enable  the  improvement  of  the  work  methods  and  procedures. 

♦  Further  understand  the  operational  information  needs  of  Groups  and  Stations 
and  the  operational  reporting  needed  to  support  Headquarters  program 
managers  and  District  operations  personnel  in  order  to  maximize  support  for 
and  minimize  impact  on  field  operations. 


2.4  Project  Approach 

The  R&D  Center  has  split  OIS  into  two  phases,  with  the  possibility  of  others  in  the  future.  This 
was  done  to  divide  the  problem  into  pieces  of  manageable  size.  Phase  I  dealt  with  Groups  and 
Stations,  and  the  Search  and  Rescue  and  Law  Enforcement  missions.  Phase  I  is  complete;  this 
report  is  its  final  R&D  milestone.  Phase  II  deals  with  Districts,  Air  Stations  and  Groups.  Like 
Phase  I,  it  supports  Search  and  Rescue  and  Law  Enforcement. 

Phase  I  began  with  a  series  of  in-depth  user  workshops  involving  operational  personnel  from 
around  the  country.  They  focused  on  (a)  defining  information-related  problems  in  current 
operations,  (b)  defining  a  set  of  solutions  to  those  problems,  and  (c)  describing  the  payoffs 
(benefits)  anticipated. 

Based  on  the  results  of  these  workshops,  the  R&D  Center  developed  a  proof-of-concept  system 
to  evaluate  the  feasibility  of  implementing  the  ideas.  The  Center  proposed  that  the  system  be 
installed  in  an  actual  operational  environment  for  several  months.  This  testbed  was  to  validate 
and  refine  the  functional  requirements  developed  during  the  workshops,  and  subject  the  system 
concepts  to  the  harsh  light  of  real-world  usage.  Therefore,  the  System  had  to  be  substantially 
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more  robust  than  a  typical  proof-of-concept.  At  the  same  time,  it  was  designed  to  achieve 
maximum  demonstrated  functionality  with  limited  effort.  Therefore,  it  is  maintenance  intensive. 
It  is  a  throwaway,  not  suited  for  operational  deployment. 

The  operational  testbed  was  also  restricted  limited  to  working  within  the  current  business  practice 
paradigm.  G-NRS  specified  that  the  proof  of  concept  effort  include  the  technical  system  only,  not 
incorporating  any  of  the  business  changes  which  were  suggested  during  the  user  workshops. 

2.5  Applicable  Documents 

The  following  documents  were  used  as  references  in  designing  and  developing  the  testbed  system, 
and  during  its  evaluation: 

1 .  Gru/Sta  OIS  System  Specification,  dated  16  November  1992. 

2.  Gru/Sta  OIS  Data  Model,  dated  26  March  1993. 

3.  Gru/Sta  OIS  Software  Unit  Specification,  dated  23  July  1993. 

4.  Gru/Sta  OIS  Problem  Tracking  System  and  Configuration  Management  Plan, 
dated  22  November  1993. 

5.  GAO  Report  -  April  1990,  Coast  Guard  Needs  to  Improve  Strategic  IRM 
Planning. 

6.  GAO  Report  -  May  1994,  Improving  Mission  Performance  Through  Strategic 
Information  Management  and  Technology. 

I.  DoD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and 
Procedures,  February  23,  1991,  Part  8,  “Cost  and  Operational  Effectiveness 
Analysis.” 

8.  0MB  Circular  No.  A- 11,  Preparation  and  Submission  of  Budget  Estimates, 

July,  1992. 

9.  FIPS  PUB  64,  Guidelines  for  Documentation  of  Computer  Programs  and 
Automated  Data  Systems  for  the  Initiation  Phase. 

10.  LEIS  II  Detailed  Software  Design  Document,  dated  6  December  1991. 

II.  COMDTINSTM5230.10A,  SARMIS Manual,  AzXqA  10  January  1992 

12.  COMDTINST  3123.7J,  Abstract  of  Operations  Reports,  dated  September 
1992. 

13.  COMDTINST  M7 110.1,  Benefit-Cost  Analysis  Manual  for  the  Acquisition  of 
Federal  Information  Processing  (FIP)  Resources  (Draft,  12/94). 
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3.  TESTBED  DESCRIPTION 

This  section  describes  the  physical  and  organizational  environment  in  which  the  OIS  concepts 
were  evaluated.  It  also  presents  an  abbreviated  Functional  Description  of  the  OIS  Phase  I  Testbed 
system.  A  more  detailed  fimctional  description  is  in  Appendix  C. 

3.1  Operational  Description 

3.1.1  Group 

Coast  Guard  Group/COTP  Long  Island  Sound  (GniLIS)  is  headquartered  in  New  Haven,  CT  and 
covers  Long  Island  Sound  from  the  East  River  in  New  York  to  Block  Island  at  the  eastern  end  of 
the  Sound.  It  includes  three  Stations,  which  are  participants  in  the  OIS  testbed;  it  also  includes  an 
82’  WPB,  a  65’  WYTL,  and  an  Aids  to  Navigation  Team  with  46’  and  55’  ANBs  and  several 
smaller  boats.  In  addition  to  traditional  Group  duties,  GruLIS  is  the  Captain  of  the  Port  for  both 
the  area  of  responsibility  described  above  and  for  the  AOR  of  Group  Moriches,  encompassing  the 
south  shore  of  Long  Island. 

Group/COTP  Long  Island  Sound  is  commanded  by  an  0-6,  with  an  0-4  Deputy  and  an  0-3 
Operations  Officer.  The  command  center  is  staffed  by  an  Operations  Duty  Officer 
(QM1/BM1/QM2/BM2)  standing  24-hour  duty,  and  a  Radioman  of  the  Watch  (RM2/3)  standing 
12-hour  duty.  During  surge  periods,  an  additional  RMOW  or  ODO  provide  augmentation. 

3.1.2  Stations 

All  three  GruLIS  Stations  were  part  of  the  testbed. 

Station  Eatons  Neck,  NY  is  in  Northport,  NY,  on  the  north  shore  of  Long  Island  in  western  Long 
Island  Sound.  It  is  commanded  by  a  Chief  Warrant  Officer  (BOSN),  and  has  a  complement  of  41 
personnel,  two  41’  UTBs,  and  one  6.4m  RHIB.  Typical  SAR  case  loading  is  from  900-1000 
cases  per  year,  with  a  significant  percentage  handled  by  Auxiliarists,  commercial  providers,  and 
local  agencies.  The  station  typically  conducts  200-300  ELT  boardings  per  year. 

Station  New  Haven,  CT  is  in  central  Long  Island  Sound.  It  is  commanded  by  a  Chief  Boatswain’s 
Mate,  and  has  a  complement  of  23  personnel,  one  41’  UTB,  and  one  6.4m  RHIB.  It  also  hosts  an 
additional  UTB,  used  as  the  Group  spare.  Typical  SAR  case  loading  is  300  cases  per  year,  with 
the  majority  involving  Station  resources  or  Auxiliarists.  Some  responses  involve  commercial 
providers  and  local  agencies.  The  station  typically  conducts  200  ELT  boardings  per  year. 

Station  New  London,  CT  is  in  the  Thames  River  in  eastern  Long  Island  Sound.  It  is  commanded 
by  a  Lieutenant,  and  has  a  complement  of  43  personnel,  two  41’  UTBs,  and  one  6.4m  RHIB. 
Typical  SAR  case  loading  is  400  cases  per  year,  with  about  half  involving  Station  resources  or 
Auxiliarists.  Responses  involving  commercial  providers  and  local  agencies  are  a  smaller 


February  1 995 


11 


USCG  Operational  Information  System 


Group/Station  OIS  Testbed  Evaluation  Report 


proportion  than  at  Eatons  Neck  but  a  larger  proportion  than  at  New  Haven.  The  station  typically 
conducts  600-700  ELT  boardings  per  year. 

3.1.3  Utility  Boats 

Prior  to  the  OIS  Testbed,  all  six  GruLIS  UTBs  carried  the  standard  UTB  electronic  outfit.  The 
CG  Headquarters  SAR  Facility  Manager,  G-NRS,  granted  permission  to  install  a  temporary 
nonstandard  suite  aboard  these  six  boats  for  the  duration  of  the  testbed.  In  the  course  of  the 
testbed  installation,  no  standard  equipment  was  removed  or  repositioned.  The  nonstandard 
equipment  was  added  in  a  non-destructive  fashion. 

3.2  Testbed  Functional  Description 

The  Functional  Description  presented  in  this  Section  is  based  on  the  Phase  One  R&D  Testbed,  as- 
built.  Appendix  C  presents  a  Functional  Decomposition  of  Phases  I  and  II.  A  number  of  features 
from  the  complete  system  were  not  implemented  in  the  testbed,  or  were  only  partially 
implemented,  because  of  time  and  budget  constraints.  These  include  managing  resources  (the 
testbed  allowed  tracking  of  resource  positions,  but  no  capabilities  descriptions,  and  no  means  of 
tracking  dynamic  operational  commander  relationships);  interactive  checklists;  access  to 
references;  tools  for  resolving  data  conflicts;  mechanisms  for  highlighting  updates;  and  assigning 
tasking  to  resources.  In  general,  the  ability  to  access  information  in  the  database  was  limited  to 
displaying  the  currently  selected  item  only;  there  were  no  query  and  report  tools  allowing  access 
to  the  entire  database. 

3.2.1  Data  Model 

The  OIS  logical  data  model  was  designed  to  support  cross-functional  integration  of  several  legacy 
systems,  thereby  consolidating  access  to  information  and  eliminating  data  entry  redundancy  (This 
eliminates  redundancy  from  the  user’s  perspective,  by  mapping  between  systems.  From  the 
system  perspective,  redundancy  remains,  and  must  be  managed).  The  systems  which  were 
included  in  this  integration  are  the  Search  and  Rescue  Management  Information  System 
(SARMIS);  the  Law  Enforcement  Information  System  II  (LEIS  II);  the  Abstract  of  Operations 
System  (Aops);  the  Coast  Guard  Boarding  Report  (form  CG-4100);  SAR  Situation  Reports 
(SITREPs);  and  information  required  by  current  command  center  checklists  and  SOP  during  the 
course  of  case  prosecution  that  does  not  feed  these  systems.  This  totaled  some  600  attributes, 
which  were  organized  into  approximately  20  entities.  The  Phase  I  data  model  is  available  under 
separate  cover.  The  design  work  in  Phase  II  has  extended  this  model. 

The  entire  data  model  was  implemented  on  the  shoreside  system.  The  mobile  system  did  not 
include  Abstract  of  Operations  summary  data,  but  provided  the  raw  input  for  Aops;  it  supported 
all  LEIS  II  and  CG4100  data,  and  all  but  a  few  summary  items  from  SARMIS. 


February  1995 


12 


USCG  Operational  Information  System _ _ Group/Station  OIS  Testbed  Evaluation  Report 

3.2.2  Major  Functional  Areas 

The  major  system  functions  are  listed  in  Table  1.  These  represent  the  most  significant  ways  in 
which  the  system  must  support  users  during  operations.  Italics  indicate  that  a  function  was  not 
implemented  in  the  Phase  I  Testbed. 


Table  1:  Major  OIS  Phase  I  Functions  (italics  indicate  items  not  implemented 

in  testbed) . 


Shoreside  Subsystem 

Utility  Boat  Subsystem 

Geographic  Information  System  (GIS)  to  integrate 
ooerational  information 

Electronic  Chart  System  to  improve  navigational  i 
accuracy  1 

1  Data  entry,  including  source  data  capture 
treauires  fast  response  for  use  during  ops) 

Source  data  capture,  diuing  SAR  and  boardings,  j 
via  pen-based  computer  i 

I  Data  distribution,  allowing  all  units  access  to 

1  shared  case  information,  including  conflict 

1  resolution  between  updates. 

Data  distribution 

:  Electronic  checklists 

Electronic  checklists  1 

\  Resource  and  facility  tracking  via  GIS 

Remote  Dependent  Surveillance  System  (RDSS)  | 
for  ops  and  position  reporting 

1  Vdi^tion  to  verify  completeness  and  accuracy  for 
i  external  system  export. 

Validation 

I  Operational  reports  consolidation  and  export  to 

1  external  systems  . 

Automatic  Report  Generation 

i  On-line  access  to  LEIS II  information 

On-line  access  to  LEIS  II  information  i 

\  Electronic  tasking  to  resources 

Electronic  tasking  and  status  reporting  i 

\  Integrated  Decisions  Aids,  such  as  CASP  and 
\  AMVER 

Integrated  Decisions  Aids,  such  as  regulation  \ 
references  on-line 

3.2.3  Shoreside  Subsystem 

The  Shoreside  Systems  at  the  Group  and  Stations  are  virtually  identical.  The  only  difference  is 
that  the  Group  system  acts  as  the  hub  of  a  star  network;  the  two  Stations  and  six  UTBs  all 
communicate  with  one  another  via  the  Group.  All  other  functional  aspects  of  the  Station  systems 
are  identical  to  the  Group  system. 

The  shoreside  subsystem,  depicted  in  Figure  1,  runs  on  Hewlett-Packard  Unix  workstations, 
model  HP-9000/750,  procured  via  the  US  Navy  Tactical  Advanced  Computer  III  (TAC-III) 
contract.  The  operating  system  is  HP’s  version  of  Unix,  HP-UX  8.07.  The  systems  use  the 
Navy’s  Unified  Build  (UB)  Government  Off  the  Shelf  Software  (GOTS)  as  a  geographic  display, 
but  do  not  use  the  UB  Track  Database  or  Communications  modules.  (These  UB  modules  do  not 
support  the  data  elements  needed  by  the  USCG  systems  to  which  OIS  must  export  data).  The 
OIS  Shoreside  System  uses  the  Progress  Relational  Database  Management  System  (RDBMS). 
Data  stored  in  the  RDBMS  is  displayed  in  a  Graphical  User  Interface;  the  interface  stores  and 
retrieves  data  via  Embedded  Structured  Query  Language  calls. 
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The  Communications  subsystem  relies  on  the  public-domain  Kermit  protocol  for  error  detection 
and  correction.  It  uses  a  COTS  product  called  Secret  Agent  for  DES-level  data  encryption, 
suitable  for  protecting  information  which  is  For  Official  Use  Only  (FOUO).  There  are  three 
communications  links;  to  other  shoreside  systems,  to  the  mobile  systems  aboard  utility  boats,  and 
to  the  CG  Standard  Workstation  for  legacy  data  export.  For  the  testbed,  all  three  links  were 
implemented  using  serial  communications.  Shoreside  communications  were  via  dial-up  modems 
and  the  public-switched  telephone  network.  Communications  between  the  boats  and  shore  were 
via  specialized  dial-up  modems  (using  the  Microcom  Networking  Protocol  10,  or  MNP- 10,  for 
error  detection  and  correction  in  the  harsh  Radio  Frequency  data  environment)  and  the  cellular 
phone  system.  Communications  to  the  CGSW  were  via  a  terminal  emulation  session  over  a  serial 
null-modem  cable. 


Figure  1:  Shoreside  Subsystem  Schematic  (Group  version  depicted) 
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From  the  user’s  point  of  view,  the  shoreside  system  was  centered  around  a  geographical 
information  system  capable  of  displaying  any  area  in  the  world.  It  usually  displayed  the  command 
center’s  Area  of  Responsibility,  and  the  current  position  and  status  of  all  resources  in  the  Group. 
Each  operational  incident  in  progress  was  represented  by  a  floating  Toolbar,  with  twelve  buttons 
for  displaying  data  about  various  aspects  of  the  case.  Clicking  on  any  of  the  buttons  accessed  a 
set  of  screens  with  related  data.  In  addition,  each  situation  was  represented  on  the  geographic 
display  by  a  symbol.  The  Toolbar  buttons  are: 

♦  Situation  Screen 

♦  Sortie  Screen 

♦  Chrono  Notes  Screen 

♦  Weather  Screen 

♦  Vessel  Screen 

♦  Person  Screen 

♦  Aircraft  Screen 

♦  Job  Aids 

♦  Data  Conflict  Review 

♦  Transmit 

♦  Validate 

♦  Put  Away 

Two  terms  with  explicit  meaning  to  OIS  are  Situation  and  Resource  Event.  A  Situation  is  similar 
to  the  typical  concept  of  a  Coast  Guard  “case,”  or  operational  response,  and  is  defined  as  a  multi¬ 
unit,  multi-mission  case.  All  information  related  to  an  operational  response  to  a  single  incident  is 
included  as  part  of  a  Situation  record,  and  is  stored  as  such  in  the  database  and  displayed  as  such 
in  the  user  interface.  A  Resource  Event  is  similar  to  the  typical  concept  of  a  sortie.  However, 
since  definitions  vary,  an  OIS  Resource  Event  is  defined  as  the  time  a  single  operational  resource 
(which  may  be  either  Coast  Guard  or  non-Coast  Guard)  is  underway  or  airborne  conducting  the 
same  primary  mission  (Abstract  of  Operations  employment  category)  in  response  to  the  same 
Situation. 

The  Situation  Screen  gave  users  access  to  summary  data  about  the  case,  including  primary 
mission,  incident  type,  key  dates  and  times.  Mission  Coordinator,  and  units  involved. 

The  Sortie  Screen  gave  users  a  list  of  all  Resource  Events  involved  in  the  Situation.  The  data 
describing  resource  events  includes  dates  and  times  underway,  on  scene,  etc.;  resource  ID, 
primary  mission  and  incident  type;  and  sortie  results  and  performance  details.  Each  resource 
event  also  has  associated  with  it  a  Job  Aid,  which  is  a  replica  of  the  checklist  associated  with  that 
incident  type. 

The  Chrono  Notes  Screen  let  users  keep  track  of  miscellaneous  information  received  during  a 
case,  just  as  they  do  with  current  Chronological  Logs.  Chrono  Notes  from  all  units  involved  in  the 
Situation  are  integrated  into  a  single  log. 
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The  Weather  Screen  allowed  users  to  describe  observed  weather  at  a  specified  location  and  time. 
The  Phase  I  system  did  not  support  automated  import  of  data  from  external  sources  such  as 
National  Weather  Service. 

The  Vessel,  Person,  and  Aircraft  Screens  each  displayed  a  list  of  these  entities  involved  in  the 
Situation.  The  list  of  entities  is  presented  in  the  upper  portion  of  the  screen,  with  the  remainder 
used  for  data  entry  and  update. 

The  Job  Aids  button  displayed  a  list  of  SAR  checklists.  The  checklists  used  for  the  Phase  I 
testbed  are  taken  from  the  First  District  Standard  Operating  Procedures  (SOP).  They  consist  of 
the  checklist  text  displayed  in  a  read-only  screen.  No  data  entry  is  possible,  because  the  Phase  I 
data  model  does  not  include  tables  for  checklists.  These  checklists  can  be  displayed  on  screen  or 
printed,  but  not  shared  between  sites. 

The  Data  Conflicts  button  displayed  a  report  of  any  conflicts  encountered  during  the  most  recent 
transmission  updating  this  case.  Upon  receipt  of  new  data,  each  incoming  data  element  was 
compared  to  its  corresponding  element  in  the  local  database.  If  they  were  different,  the  local 
database  was  not  overwritten,  and  the  incoming  data  element  was  displayed  for  the  user  to  resolve 
the  conflict.  It  displayed  these  as  a  text  report  which  could  be  viewed  on  screen  or  printed.  Users 
could  read  the  conflict  report,  then  navigate  to  the  appropriate  screens  in  order  to  update  the 
fields  in  question.  The  shoreside  did  not  implement  any  way  of  identifying  which  data  in  an 
incoming  datagram  was  new.  Since  OIS  transmitted  the  entire  electronic  case  folder  on  each 
transmission,  the  user  had  no  way  to  identify  which  information  was  new.  The  Phase  I  testbed 
system  did  not  provide  an  easy-to-read  case  summary  report.  The  only  outputs  available  were  a 
draft  SITREP  and  a  lengthy  listing  of  the  entire  database  contents. 

The  Transmit  button  controlled  routing  of  OIS  data.  The  first  time  a  user  clicked  this  button 
during  a  given  Situation,  the  Transmit  Control  Window  opens.  This  window  presented  a  list  of 
possible  recipients  for  copies  of  this  Situation.  From  then  on,  whenever  the  user  clicked  the 
Transmit  button,  the  update  was  sent  to  all  marked  Recipients.  The  Phase  I  testbed  system  did 
not  differentiate  among  recipients;  all  had  full  privileges  to  update  data. 

The  Validate  button  initiated  a  check  of  the  data  in  this  Situation  by  the  OIS  Validation  module. 
This  feature  examined  the  data  from  the  Situation  represented  in  the  selected  Toolbar  for 
compliance  with  all  requirements  of  the  external  systems.  This  check  preceded  all  exports  of  data 
from  the  shoreside  OIS  system  to  existing  Coast  Guard  information  systems  such  as  SARMIS, 
LEIS  II  and  AOps.  Missing  data  was  flagged  for  the  user  to  fill  in.  Upon  successful  Validation, 
the  data  could  be  exported  to  the  Coast  Guard  Standard  Workstations  for  insertion  into  the 
existing  systems.  (See  the  Reports  Controller  description). 

The  Put  Away  button  dismissed  the  Toolbar  for  the  selected  Situation,  removing  it  from  the 
screen.  The  case  data  remained  in  the  database  unchanged,  available  for  future  editing.  This 
simply  cleared  the  screen. 

In  the  Phase  I  testbed,  the  data  model  was  built  to  allow  most  tables  (entities)  to  be  accessed 
independently  of  any  particular  Situation.  However,  the  Phase  I  testbed  did  not  implement 
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screens  to  allow  cross- Situation  access  to  these  entities.  For  instance,  the  only  way  to  find  a 
vessel  via  the  application  screens  is  to  know  what  Situation  it  was  involved  in,  edit  the  Situation, 
then  open  the  Vessel  screen.  The  only  query  and  report  capabilities  in  the  Phase  I  testbed  are 
achieved  using  adhoc  queries  in  SQL  or  4GL.  However,  there  is  no  underlying  technical 
limitation  preventing  the  implementation  of  user-fiiendly  query  screens  allowing  this  type  of 
cross-Situation  access  to  vessels,  people,  weather,  chronos,  etc. 

The  Phase  I  shoreside  system  also  allowed  users  to  enter  non-Coast  Guard  resource  information 
in  a  category  called  “Excoms.”  These  are  non-mobile  resources,  such  as  marinas,  hospitals,  fire 
departments,  and  police  departments.  The  name  Excom  is  taken  from  the  National  SAR  Manual’s 
term  for  Extended  Communications  Search,  since  these  facilities  are  often  called  during  an 
Excom.  However,  a  more  generic  name,  such  as  facilities,  would  be  less  restrictive  and  more 
suitable  in  the  fixture.  Phase  I  includes  a  single  database  table  called  Excom  which  allows 
unlimited  total  records,  with  one  record  for  each  facility  to  be  described.  The  fields  include 
latitude,  longitude,  phone  number,  point  of  contact,  an  icon  code,  and  Excom  name.  Each  Excom 
is  represented  on  the  electronic  chart  by  an  icon. 

3.2.4  Utility  Boat  Subsystem 

The  Utility  Boat  subsystem  consisted  of  several  interconnected  hardware  platforms,  as  depicted  in 
Figure  2.  Most  user  interaction  was  with  a  portable  pen-based  computer.  The  testbed  used  an 
IBM  PC-compatible  computer  manufactured  by  Telepad  Corporation  and  based  on  the  Intel 
80386SL  CPU  operating  at  25  MHz.  This  machine  weighed  3.5  pounds,  and  allowed  data  entry 
either  by  a  traditional  keyboard  (detachable)  or  by  writing  and  tapping  an  electronic  pen  directly 
on  the  screen.  The  computer  could  be  carried  like  a  clipboard  and  powered  by  batteries  for  up  to 
2.5  hours.  This  computer  hosted  the  mobile  part  of  the  “electronic  case  folder,”  and  was  designed 
to  be  carried  by  Coast  Guard  boarding  officers  during  law  enforcement  boardings.  A  lightweight 
printer  was  used  to  print  out  receipts  for  the  boater.  The  Telepad  ran  Microsoft  Corp’s 
“Windows  for  Pen  Computing”  operating  system,  version  1.0.  This  is  based  on  Microsoft 
Windows  3.1,  with  extensions  to  support  handwriting  recognition. 
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Figure  2:  Utility  Boat  subsystem  schematic. 

The  other  major  component  of  the  boat  subsystem  was  an  ffiM-PC  compatible  computer 
mounted  permanently  aboard  the  UTB.  This  machine  acted  as  a  communications  server,  and  also 
ran  a  COTS  Electronic  Chart  System  (ECS)  software  package.  The  ECS  received  position 
information  from  a  Differential  Global  Positioning  System  (dGPS)  receiver,  and  displayed  the 
UTB’s  current  position  on  an  electronic  chart.  The  communications  server  buffered  messages 
between  the  shoreside  system  and  the  pen-based  computer.  The  computer  was  highly  ruggedized, 
and  enclosed  in  a  watertight  housing.  It  used  an  80486-compatible  CPU  from  Cyrix  corporation. 
The  communications  to  shore  were  handled  by  a  Microcom  modem  using  the  MNP- 10  error 
detection  and  correction  protocol,  which  is  optimized  for  cellular  telephony.  The  COTS  ECS 
software  package  was  MapTech  Corp’s  “Pilot”  software.  Pilot  is  MapTech’s  low-end  ECS 
package,  providing  basic  ECS  functionality:  current  position  display;  20  waypoint  route  planning; 
navigation  error  indicators;  alarms;  and  track  logging.  These  functions  are  with  the  standard  for 
Electronic  Chart  Systems  (but  not  for  the  more-capable  Electronic  Chart  Display  Information 
Systems,  ECDIS).  In  addition  to  providing  own-ship  navigation,  this  computer  forwarded  the 
boat’s  position  to  the  shoreside  system  with  each  user-requested  transmission,  and  automatically 
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every  fifteen  minutes.  OIS  thus  provided  Remote  Dependent  Surveillance  System  (RDSS) 
capability. 

The  OIS  mobile  application  which  ran  on  the  pen-based  computers  provided  data  entry  screens 
for  a  subset  of  the  data  in  the  shoreside  system.  The  items  not  supported  on  the  mobile 
application  are  primarily  those  which  are  related  to  end-of-quarter  Abstract  of  Operations 
processing.  The  design  goal  was  to  maximize  similarity  between  the  mobile  application  and  the 
shoreside  application,  in  order  to  minimize  cross-training  requirements.  The  screens  were  not 
exactly  the  same,  however,  for  two  reasons.  First,  the  screen  size  of  10”  diagonal  measure 
limited  the  number  of  data  elements  that  could  be  grouped  on  an  individual  screen,  especially  for 
fields  that  required  handwriting-optimized  screen  elements,  which  are  larger.  Second,  the  mobile 
application  supported  fewer  data  elements,  described  above. 

During  Law  Enforcement  boardings,  the  boarding  officer  used  the  pen-based  computer  to  capture 
all  data  about  the  boarding  to  support  both  the  Boarding  Report,  form  CG-4100,  and  the  Law 
Enforcement  Information  System  II  (LEIS  II).  The  boater  received  a  printed  report  about  the 
size  of  a  cash  register  receipt,  2.25  inches  wide  and  8  to  10  inches  long.  Back  aboard  the  USCG 
utility  boat,  the  pen-based  computer  was  connected  to  the  Communications  Server  computer  by 
an  RS-232  serial  cable.  The  communications  server  received  the  data  from  the  pen-based 
computer  using  the  Ymodem  protocol  for  error  detection  and  correction.  The  communications 
server  then  encrypted  the  data  using  Secret  Agent,  and  forwarded  it  to  the  Group’s  shoreside 
system  using  the  MNP- 10  protocol  for  error  detection  and  correction.  The  Group  system 
automatically  routed  data  to  the  parent  OPFAC  of  the  transmitting  utility  boat,  so  that  it  was 
available  at  the  Station. 

During  SAR  cases,  the  mobile  application  was  designed  to  allow  the  boat  crew  to  either  actively 
enter  data,  or  simply  receive  it  from  shore.  When  data  was  received  from  shore,  however,  there 
was  not  a  report  capability  which  showed  the  entire  case  summary  in  one  screen.  Rather,  the  user 
had  to  navigate  through  the  various  screens  to  retrieve  case  facts.  The  mobile  application  was  not 
built  around  an  RDBMS,  like  the  shoreside.  Instead,  it  relied  on  flat  files  for  data  storage.  The 
implementation  of  the  flat  file  storage  did  not  provide  a  data  conflict  handling  mechanism.  There 
was  no  mechanism  for  the  pen-based  system  to  automatically  alert  the  user  that  files  were  waiting 
on  the  communications  server  computer.  Users  had  to  be  notified  by  voice  radio  from  shore 
when  new  data  was  sent,  then  change  screens,  and  tap  a  button  to  tell  the  communications  server 
to  send  files  it  had  received  from  shore  to  the  pen-based  system. 

The  boat’s  current  position  could  be  sent  from  the  ECS  computer  to  the  pen-based  system  on 
request,  by  changing  to  the  Transmit  screen  and  tapping  a  button. 

At  the  start  of  a  new  Situation,  if  two  different  units  began  collecting  data  at  the  same  time,  they 
were  actually  creating  two  different  Situations  (the  database  key  fields  are  assigned  automatically 
at  Notification  time).  The  Phase  I  Testbed  did  not  implement  a  capability  to  merge  Situations. 
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3.2.5  System  Security 

OIS  is  an  unclassified  system.  Some  of  the  information  handled  (Law  Enforcement  tasking  and 
boarding  reports)  is  For  Official  Use  Only.  Other  parts  (any  information  about  people)  are 
Privacy  Act  sensitive. 

During  the  Phase  I  Testbed,  OIS  shoreside  systems  were  installed  in  areas  with  physical  security 
in  the  form  of  controlled  access.  These  were  Group  and  Station  Operation  Centers  and 
Communication  Centers.  Group  Long  Island  Sound  has  undergone  formal  certification  of  its 
spaces,  and  the  Stations  had  not. 

OIS  Shoreside  systems  required  a  username  and  password  for  any  access.  OIS  mobile  systems 
implemented  a  login  screen  offering  username  and  password  control,  but  its  use  was  discontinued 
because  of  difficulties  with  entering  a  password  with  the  electronic  pen.  Users  could  not  tell 
when  characters  were  misrecognized  by  the  system,  and  so  had  difficulty  gaining  authorized 
access  Future  versions  will  need  an  improved  method  of  access  control  beyond  standard 
password  schemes. 

All  OIS  communications  were  protected  by  DES  encryption.  This  encryption  was  implemented  in 
software,  using  a  COTS  encryption  package  called  Secret  Agent,  by  Information  Security 
Corporation.  OIS  created  a  separate  file  for  each  transmission.  These  were  encrj^ted  using 
Secret  Agent’s  public  key/private  key  scheme.  El  Gamal  key  management  is  built  into  Secret 
Agent,  eliminating  the  need  to  manually  distribute  key  material. 

Privacy  Act  constraints  that  apply  to  LEIS  II  were  adopted  for  OIS.  Specifically,  LEIS  II  does 
not  provide  a  capability  to  search  its  Sighting  and  Boarding  Histories  for  information  on  specific 
people.  For  instance,  there  are  no  standard  queries  that  allow  you  to  ask  “which  boardings  has 
John  Doe,  SSN  123456789,  been  involved  in?”  However,  LEIS  II  does  support  person  queries  in 
its  Lookout  database.  Similarly,  the  Phase  I  Testbed  does  not  support  such  queries,  and 
developers  of  future  versions  will  need  to  do  research  on  the  Privacy  Act  implications  before 
implementing  such  queries. 
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4.  DATA  COLLECTION  AND  EVALUATION  PLAN 

This  section  describes  the  approach  for  assessing  the  value  of  OIS  to  the  Coast  Guard.  The 
approach  includes  both  objective  and  subjective  measures  of  functions  incorporated  into  the  Phase 
I  Testbed  system,  and  calculated  (theoretical)  measures  for  items  that  were  not  included  in  the 
Testbed  system  but  are  part  of  the  target  system. 

The  evaluation  tools  used  include;  time  studies,  with  both  self-logging  and  third  party  observers; 
questionnaires;  user  interviews;  workshops;  the  technical  team’s  Problem  Tracking  System  for 
system  problems;  User  Comments  entered  directly  into  the  system;  and  impromptu  meetings 
between  support  personnel  and  users  during  the  course  of  providing  training  and  technical 
support. 

4.1  Hypotheses 

The  evaluation  approach  began  with  the  development  of  a  set  of  hypotheses  regarding  the 
expected  benefits  of  OIS.  These  are  derived  from  the  Problem  Statements  and  Research 
Objectives  in  Section  I,  and  form  the  foundation  for  this  evaluation.  The  hypotheses  are: 

A.  OIS  will  reduce  data  entry  and  report  preparation  time. 

B.  OIS  will  increase  accuracy  and  completeness  of  reports. 

C.  OIS  will  improve  command  and  control  (C^)  by  reducing  C^  response  time. 

D.  OIS  will  improve  navigational  accuracy  of  standard  boats. 

E.  OIS  will  provide  better  on-scene  information  to  field  personnel. 

4.2  Objective  Metrics 

The  evaluation  team  defined  18  metrics  as  candidates  for  objective  measurement  during  the 
Group/Station  OIS  Testbed  in  Group  Long  Island  Sound.  Of  these,  eight  were  selected  for  use. 
The  choices  were  based  on  (1)  feasibility  of  data  collection,  and  (2)  whether  or  not  the  item  to  be 
measured  was  included  in  the  Phase  I  Testbed  system,  and  therefore  available  for  measurement. 
Each  was  described  in  detail  on  data  collection  worksheets  for  the  field  users.  These  are 
displayed  in  Appendix  B. 

Baseline  data  were  collected  for  several  of  these  metrics.  The  evaluation  plan  called  for  two 
measurements,  one  early  in  the  testbed  and  another  two  to  three  months  later,  to  measure  the 
effects  of  training  and  hands-on  use.  However,  because  of  the  time  required  for  technical  support 
of  the  testbed  system,  only  one  round  of  measurement  was  achieved,  late  in  the  testbed.  Pre-OIS 
baseline  data  were  collected  in  Group  Moriches,  New  York  (on  the  south  shore  of  Long  Island). 
Analysis  of  historical  SARMIS  and  SEER  data,  and  discussion  with  CGDl(osr)  and  (ole)  staff 
indicated  that  the  activity  levels  were  similar  enough  that  the  comparison  would  be  valid. 
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For  statistical  reliability,  it  was  found  necessary  to  collect  a  minimum  of  20  samples  in  support  of 
each  individually  numbered  metric;  30  samples  were  recommended.  The  basis  for  this 
determination  was  an  assumption  (later  proven  true  via  baseline  data  collection)  that  90%  of 
SARMIS  reports  take  between  six  and  twenty  minutes  to  complete.  This  gives  a  mean  of  thirteen 
minutes  and  a  standard  deviation  of  4.24  minutes.  Sample  size  was  estimated  by  two  different 
techniques;  (1)  a  t-test,  with  an  expected  pre-  and  post-OIS  mean  difference  of  3  minutes,  and 
two-tailed  alpha-level  of  .05;  and  (2)  an  estimate  based  on  a  moderate  effect  size  (percent 
variance  accounted  for  equal  to  25%),  two-tailed  alpha-level  of  .05,  and  power  equal  to  .95.  A 
sample  size  of  20  is  sufficient  for  both  these  conditions.  SEER  times  were  estimated  to  be  similar 
for  the  purposes  of  the  sample  size  calculation. 

All  18  candidate  metrics  and  the  hypotheses  they  support  are  listed  below.  The  ones  selected  for 
measurement  are  italicized.  Metrics  1  and  2  are  similar  to  metrics  8-11;  the  difference  is  that  1&2 
apply  to  field  personnel  (boat  crews),  while  8-1 1  apply  to  command  center  personnel  (OODs, 
RMOWs,  watchstanders). 

A.  OIS  will  reduce  data  entry  and  report  preparation  time. 

1.  Time  to  enter  data  in  the  field 

2.  Time  to  transcribe  data  in  the  field 

3.  Time  to  prepare  reports 

4.  Time  spent  on  adhoc  (on-request)  reports 

5.  Amount  of  overtime 

B.  OIS  will  increase  accuracy  and  completeness  of  reports. 

6.  Number  of  errors  detected  in  manual  case  reviews 

7.  Number  of  required  and  optional  fields  missing  from  reports 

C.  OIS  will  improve  command  and  control  by  reducing  response  time. 

8.  Time  to  record  data  (at  initial  distress  call) 

9.  Time  to  transcribe  data  into  OIS 

10.  Time  to  identify  resources 

11.  Time  to  dispatch 

D.  OIS  will  improve  navigational  accuracy  of  standard  boats. 

12.  Search  pattern  execution  accuracy 

E.  OIS  will  provide  better  on-scene  information  to  field  personnel. 

13.  Number  of  effective  LE  boardings 

14.  Number  of  LEIS  violations  overturned 

15.  Number  of  recreational  boating  safety  violations 

16.  Number  of  manuals  accessed  on  board 

17.  Number  of  queries  to  LEIS  II 

18.  Avoid  doing  the  wrong  boardings 

4.2.1  Issues  Regarding  Measurement 

The  OIS  testbed  began  in  the  late  spring,  as  Group  Long  Island  Sound  was  entering  its  peak 
operational  season.  Typically,  when  people  are  under  time  pressure,  they  prefer  to  do  things  in  a 
familiar  way.  Therefore,  they  would  be  less  apt  to  spend  the  time  to  learn  a  new  system,  even  if 
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there  are  long-term  savings  associated  with  using  the  new  system.  In  order  to  get  a  usefiil 
evaluation  of  OIS,  it  was  deemed  imperative  to  provide  group  and  station  personnel  with  as  much 
up-ffont  training  and  familiarization  as  possible.  This  was  done  via  a  training  ramp-up  schedule 
which  started  several  months  before  the  testbed  system  was  actually  installed. 

Another  concern  had  to  do  with  having  the  group  and  station  personnel  log  the  times  required  for 
certain  activities.  A  part  of  this  concern  was  that  we  may  be  overtaxing  an  already-busy  group  of 
people.  A  related  concern  was  that  busy  people  may  opt  not  to  record  the  data  (either  not  record 
it  at  all  or  give  guesstimates),  which  would  reduce  the  accuracy  of  our  data.  Also,  since  these 
personnel  are  often  involved  in  multiple  cases  simultaneously,  it  might  be  impossible  for  them  to 
give  good  estimates  of  how  much  time  they  spent  on  any  given  case.  For  example,  they  might 
start  to  transcribe  data  into  OIS  and  be  interrupted  by  a  phone  call.  Minutes,  or  even  hours, 
might  elapse  before  they  return  to  the  transcription  task.  In  this  case,  it  would  be  very  difficult  to 
estimate  how  much  time  the  transcription  took.  Because  of  this,  the  data  may  be  very  messy,  and 
only  very  large  effects  of  OIS  might  become  apparent.  (This  concern  was  in  fact  borne  out.  The 
discussion  in  Section  4  regarding  Hypotheses  A  and  C  contains  details.) 

4.2.2  Analysis  Plan 

Pre-and  post-OIS  time  study  data  were  compared.  If  the  mean  time  to  perform  a  task  using  OIS 
is  less  than  the  mean  time  to  perform  that  task  using  pre-OIS  methods,  and  the  difference  is 
determined  to  be  statistically  significant,  the  hypothesis  is  considered  valid  to  a  stated  degree  of 
confidence.  The  degree  of  confidence  were  tested  using  Student’s  t-test.  This  test  assumes  that 
the  time  data  are  distributed  normally. 

The  following  specific  comparisons  were  made,  supporting  the  indicated  metric: 

1.  Time  to  enter  data  in  the  field:  The  time  required  by  field  personnel  (boat  crews)  to 

capture  data  the  first  time  using  pre-OIS  methods  (paper  and  pencil)  were 
compared  to  the  time  required  after  OIS  is  installed.  If  a  post-OIS  user  captures 
data  using  paper  and  pencil,  that  is  what  was  measured  here;  time  to  transcribe  it 
into  OIS  is  addressed  in  metric  2.  (It  was  not  expected  that  there  would  be 
significant  SAR-related  data  entry  by  field  personnel,  either  pre-  or  post-OIS.  Case 
documentation  is  almost  entirely  maintained  ashore  in  current  practice.  Metrics  1 
and  2  were  be  used  to  assess  whether  OIS  changed  this  paradigm.)  The  raw  data 
were  captured  by  an  observer  using  the  data  collection  sheets  in  Appendix  B. 

2.  Time  to  transcribe  data  in  the  field:  The  time  required  by  field  personnel  (boat  crews) 

to  transcribe  data  after  its  initial  capture  using  pre-OIS  methods  (paper  and 
pencil)  was  compared  to  the  time  required  after  OIS  is  installed.  If  a  post-OIS 
user  captures  data  using  paper  and  pencil,  the  time  measured  here  represents  time 
spent  entering  it  into  the  OIS  screens  from  the  hand-written  notes.  Pre-OIS 
transcription  is  counted  as  time  spent  copying  notes  from  scrap  paper  into  the 
official  chrono  log  or  case  folder,  even  if  this  happens  after  the  boat  crew  returns 
to  base.  The  raw  data  were  captured  by  an  observer  using  the  data  collection 
sheets  in  Appendix  B. 
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3.  Time  to  prepare  reports:  The  time  to  complete  a  SARMIS  report  was  compared  to  the 
time  required  to  validate  a  SAR  case  using  OIS.  The  time  to  complete  a  SEER 
report  after  each  boarding  was  compared  to  the  time  to  validate  the  boarding 
information  using  Operational  Information  System.  The  raw  data  were  captured 
by  user  self-logging  using  the  data  collection  sheets  in  Appendix  B. 

7.  Number  of  required  and  optional  fields  missing  from  reports:  A  random  sample  of 

20  case  folders  were  selected  from  a  unit’s  SAR  case  files.  Each  folder  was 
reviewed  to  determine  whether  any  data  elements  were  missing.  If  any  were 
missing,  they  were  noted.  The  total  number  of  missing  fields  were  normalized  the 
entire  sample. 

8.  Time  to  record  data  (at  initial  distress  call):  The  time  required  by  command  center 

personnel  to  capture  data  the  first  time  using  pre-OIS  methods  (paper  and  pencil) 
was  compared  to  the  time  required  after  OIS  is  installed.  If  a  post-OIS  user 
captures  data  using  paper  and  pencil,  that  is  what  was  measured  here;  time  to 
transcribe  it  into  OIS  is  addressed  in  metric  9.  The  raw  data  were  captured  by  an 
observer  using  the  data  collection  sheets  in  Appendix  B. 

9.  Time  to  transcribe  data  into  OIS:  The  time  required  by  command  center  personnel  to 

transcribe  data  cifter  its  initial  capture  using  pre-OIS  methods  (paper  and  pencil) 
was  compared  to  the  time  required  after  OIS  is  installed.  If  a  post-OIS  user 
captures  data  using  paper  and  pencil,  the  time  measured  here  represents  time  spent 
entering  it  into  the  OIS  screens  from  the  hand-written  notes.  Pre-OIS 
transcription  is  counted  as  time  spent  copying  notes  from  scrap  paper  into  the 
official  chrono  log  or  case  folder.  The  raw  data  were  captured  by  an  observer 
using  the  data  collection  sheets  in  Appendix  B. 

10.  Time  to  identify  resources:  The  time  required  to  choose  and  assign  the  SRU  for  a 

SAR  case  was  measured,  pre-  and  post-OIS.  This  time  includes  total  person- 
minutes  expended  by  command  center  personnel  in  trying  to  locate  SRUs, 
ascertain  current  operational  status,  and  decide  which  to  assign.  The  raw  data  were 
captured  by  an  observer  using  the  data  collection  sheets  in  Appendix  B. 

11.  Time  to  dispatch:  The  time  required  to  draft  tasking  orders  and  relay  them  to  the 

resource  was  measured,  pre-  and  post-OIS.  This  time  includes  total  person- 
minutes  expended  by  command  center  personnel  in  creating  an  action  plan  or 
search  plan,  checking  it,  picking  search  area  descriptors  off  the  chart,  drafting  the 
action  message,  and  communicating  the  data  to  the  resource.  It  does  not  include 
time  spent  aboard  the  resource  in  receiving  and  interpreting  the  plan.  The  raw  data 
were  captured  by  an  observer  using  the  data  collection  sheets  in  Appendix  B. 

4.2.3  Experiment  Design 

The  next  three  subsections  describe  the  experiments  which  were  designed  to  test  these  hypotheses 
and  metrics.  The  results  and  analyses  are  presented  in  Section  4,  Research  Results.  Complete 
raw  data  are  presented  in  Appendix  A. 
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4.2.3.1  Experiment  1:  Time  Study 

This  experiment  was  designed  to  test  hypotheses  A  and  C,  metrics  1,2,8,9,10,  and  1 1.  The  goal 
of  the  time  study  was  to  understand  the  amount  of  time  operational  personnel  spend  handling 
various  types  of  information  during  operations,  broken  down  into  the  six  categories  described  in 
the  individual  metrics. 

Control  Group:  Observers  were  assigned  to  the  command  center  at  each  unit  involved  in  the 
testbed,  and  to  both  boat  crews  at  each  station.  The  observation  was  conducted  on  two  busy 
summer  weekends.  Observers  were  posted  in  shifts,  so  that  operational  personnel  were  observed 
fi-om  0800  until  2359  both  Saturday  and  Sunday;  basically,  the  plan  called  for  a  “saturation  study” 
during  a  typical  busy  summer  weekend,  during  which  approximately  50-60  single-unit  SAR  cases 
could  be  expected.  Each  observer  was  instructed  to  watch  for  information  handling  activities. 
For  each  information  transaction,  the  observer  was  to  measure  the  time  spent  handling  that 
transaction,  the  originator  and  the  recipient,  and  the  nature  of  the  transaction.  If  the  nature  was 
SAR  or  LE,  the  observer  was  also  to  record  the  case  number.  All  operating  units  in  the  testbed 
had  simultaneous  coverage.  The  time  study  was  scheduled  to  be  conducted  once  pre-OIS,  and 
again  post-OIS. 

As  a  backup  to  direct  observation,  system  users  were  asked  to  answer  a  questionnaire  assessing 
whether  OIS  helped  them  handle  information  more  easily  during  operations.  The  questionnaire 
responses  are  discussed  in  the  subjective  metrics  section. 

Test  Group:  The  same  group  of  observers  were  assigned  to  conduct  the  same  study  after  OIS 
had  been  in  use  for  about  two  months.  This  length  of  time  was  chosen  in  order  to  allow  OIS  user 
familiarity  to  stabilize  before  conducting  the  post-OIS  measures. 

4. 2. 3. 2  Experiment  2:  Report  Preparation  Time 

This  experiment  was  designed  to  test  Hypothesis  A,  metric  3. 

Control  Group:  Users  of  the  existing  Search  and  Rescue  Management  Information  System  / 
Data  Entry  System  (SARMIS/DES)  system  were  asked  to  record  time  required  to  enter 
SARMIS/DES  data  for  each  SAR  case  during  spring  and  summer  1994.  This  represented  the 
baseline  data  for  comparison  with  OIS.  SARMIS/DES  data  entry  is  performed  after  the  case  is 
complete.  The  information  has  previously  been  entered  by  hand  into  paper  case  folders  and 
checklists.  The  baseline  group  also  recorded  the  time  required  to  report  law  enforcement 
information  using  the  existing  SEER  system.  This  information  is  reported  after  the  boarding  is 
complete,  and  is  transcribed  from  the  Boarding  Form  (Boardings),  or  from  some  form  of  local  log 
(Sightings). 

Test  Group:  Users  of  the  OIS  testbed  system  were  asked  to  record  time  required  to  validate 
SAR  cases  entered  into  OIS.  OIS  encourages  users  to  enter  data  as  it  becomes  available  during  a 
case.  Further,  it  analyzes  the  “case  folder”  and  provides  a  report  describing  which  information  is 
necessary  to  complete  the  documentation.  The  time  required  to  record  data  during  the  case  could 
not  be  measured  (experiment  1).  The  important  difference  between  pre-OIS  and  post-OIS 
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methods,  however,  is  how  much  time  OIS  saves  in  after-the-case  documentation.  This  is 
validation  time,  and  is  directly  comparable  to  the  SARMIS  data  entry  time,  OIS  users  were  also 
asked  to  record  validation  time  for  LE  Boardings.  The  data  were  entered  into  OIS  using  the 
pen-based  computer,  then  transferred  to  the  shoreside  system.  In  a  fashion  similar  to  SARMIS, 
the  LE  validation  time  is  compared  to  total  SEER  time. 

Test  Group  Modification:  The  Test  Group  sample  size  for  SARMIS  data  was  not  sufficient  for 
statistical  significance  (see  Research  Results  section  for  details).  Therefore,  the  following 
controlled  experiment  was  designed  to  simulate  the  actual  test  group  conditions  as  closely  as 
possible.  Two  non-rated  personnel  from  a  Station  which  had  been  involved  in  the  testbed  were 
selected  to  participate  in  the  test.  They  were  chosen  because  they  had  been  assigned  as 
communications  watchstanders  during  the  testbed,  and  were  therefore  typical  users  of  the 
shoreside  system.  49  SAR  cases  were  chosen  at  random  from  OIS  for  them  to  re-validate.  The 
cases  were  actual  ones  which  had  been  prosecuted  and  entered  into  OIS  during  the  testbed.  They 
were  “de-validated”  by  the  tester,  by  deleting  40  data  elements  from  each  case.  Data  elements 
deleted  were  typical  of  those  which  would  not  normally  be  populated  at  the  end  of  the  case. 

4.13.3  Experiment  3:  Report  Completeness 

This  experiment  was  designed  to  test  Hypothesis  C,  using  metric  7. 

Control  Group:  The  comparison  standard  for  this  experiment  is  a  completely  populated  case 
folder.  This  includes  all  information  required  in  distress  checkoff  sheets,  case  folders, 
chronological  logs,  SITREPs,  SARMIS,  and  incident  checklists. 

Test  Group:  Twenty  traditional  SAR  case  folders  (paper  files,  not  OIS)  were  selected  from  a 
Station’s  files  at  random.  All  information  in  each  of  these  case  folders  was  reviewed  by  a  team  of 
field  personnel  who  were  experienced  in  case  prosecution  and  documentation.  They  determined 
which  data  was  required  for  proper  documentation  of  each  incident  type,  and  then  whether  or  not 
it  was  present.  After  this  analysis  was  complete,  they  transcribed  into  the  OIS  Shoreside  System 
and  ran  the  Validation  module. 

4.3  Subjective  Metrics 

Many  OIS  benefits  are  intangibles,  and  do  not  lend  themselves  well  to  quantitative  measures. 
These  were  addressed  in  user  questionnaires,  interviews,  workshops,  the  Problem  Tracking 
System,  User  Comments,  and  impromptu  meetings  between  support  personnel  and  users  during 
the  course  of  providing  training  and  technical  support. 

The  first  of  these  methods,  questionnaires,  allows  assessment  of  the  strength  of  a  group’s  opinions 
by  ranking  scales.  To  gather  these  data,  four  separate  questionnaires  were  designed,  targeted  at 
the  following  classes  of  user: 

♦  Command  Center  personnel 

♦  Operational  reporting  personnel 

♦  Coxswains 
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♦  Boarding  Officers 

4.3.1  Analysis  Plan 

The  questionnaire  responses  were  tallied,  and  frequency  distributions  of  the  responses  prepared. 
These  frequency  distributions  indicated  positive  or  negative  user  opinion  about  certain  features, 
and  the  strengths  of  those  opinions.  Users  were  also  asked  to  offer  comments  about  each 
question.  Analysts  used  these  opinions  to  assess  technical  adequacy  of  the  testbed  system,  and  as 
a  framework  for  crafting  follow-up  questions. 
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5.  RESEARCH  RESULTS 

The  hypotheses  are  restated  below  in  bold  print.  The  metrics  selected  for  evaluation  are  included. 

A.  OIS  will  reduce  data  entry  and  report  preparation  time. 

/.  Time  to  enter  data  in  the  field 

2.  Time  to  transcribe  data  in  the  field 

3.  Time  to  prepare  reports 

B.  OIS  will  increase  accuracy  and  completeness  of  reports. 

7.  Number  of  required  and  optional fields  missing  from  reports 

C.  OIS  will  improve  command  and  control  by  reducing  Cf  response  time. 

8.  Time  to  record  data  (at  initial  distress  call) 

9.  Time  to  transcribe  data  into  OIS 

10.  Time  to  identify  resources 

11.  Time  to  dispatch 

D.  OIS  will  improve  navigational  accuracy  of  standard  boats. 

£.  OIS  will  provide  better  on-scene  information  to  field  personnel. 

From  the  proof  of  concept  perspective,  the  OIS  Phase  I  project  was  an  unqualified  success. 
Opportunities  for  improved  effectiveness  were  revealed  in  many  diverse  areas.  Users  testified  to 
the  potential  of  OIS  in  relation  to  their  daily  duties,  and  Commanding  Officers  attested  to  its 
potential  for  dramatic  effectiveness  improvements  and  positive  impact  on  the  operations  of  their 
units.  This  consensus  was  tempered,  as  expected,  by  the  use  of  the  word  “potential.”  There 
were  significant  technical  and  implementation  problems  in  the  testbed  which  must  be  resolved 
before  moving  forward  with  the  concept.  Without  exception,  these  were  related  to  the  nature  of 
prototyping,  in  which  time  and  money  limit  the  robustness  of  the  project.  The  OIS  Phase  I 
testbed  did  not  reveal  any  conceptual  problems. 

The  hypothesis  that  OIS  would  decrease  workload  associated  with  operational  reporting  was 
proven  with  extremely  high  levels  of  statistical  significance.  During  the  OIS  Phase  One  Testbed, 
the  source  data  capture  for  SAR  cases  on  the  shoreside  systems  resulted  in  over  60%  time  savings 
associated  with  SARMIS  and  SEER  report  preparation.  User  suggestions  and  technical  team 
redesign  lessons  during  the  testbed  could  reduce  that  figure  even  further.  The  results  strongly 
suggest  that  nearly  all  current  operational  reporting  could  be  eliminated,  replaced  by  a  short 
period  of  review  at  the  end  of  each  case. 

The  hypothesis  that  OIS  would  increase  completeness  of  operational  reports  was  also  proven. 
The  amount  of  data  that  was  missing  from  manually  prepared  case  folders  was  a  surprise  to 
everyone  involved.  The  ability  to  improve  completeness  is  especially  important  during 
operations. 

The  hypothesis  that  OIS  would  improve  command  and  control  (C^)  was  not  proven  during  the 
OIS  Phase  One  Testbed.  However,  users  responded  uniformly  in  interviews  and  workshops  that 
the  failure  to  improve  was  a  result  of  implementation  flaws,  both  in  features  not  implemented 
and  in  software  bugs.  The  most  significant  features  lacking  were  (a)  the  ability  to  display 
meaningful  reports,  including  case  summaries  and  new  data  summaries,  both  ashore  and  afloat;  (b) 
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the  ability  for  the  user  to  easily  reconcile  conflicts  between  data  held  locally  and  data  received 
from  other  units;  and  (c)  the  frequent  failures  in  communication  (over  10%),  which  destroyed  user 

confidence. 

The  hypothesis  that  OIS  would  improve  the  navigational  accuracy  of  standard  boats  was  strongly 
supported  by  the  subjective  metrics,  including  questionnaires  and  interviews.  Users  unanimously 
endorsed  the  idea  of  using  electronic  chart  systems  to  improve  navigational  accuracy  and  reduce 
risk  of  grounding  in  small  boat  operations.  They  had  only  one  basic  concern,  which  was  policy- 
related:  '"What  happens  if  I  run  aground  using  the  ECS  and  I  don ’t  have  a  paper  plot?  This 
question  stems  from  the  fact  that  this  was  a  proof  of  concept.  It  can  be  answered  by  issuing  a 
policy  statement  in  advance  of  deployment. 

The  hypothesis  that  OIS  would  improve  availability  of  information  to  field  personnel  was  not 
proven.  The  lack  of  meaningful  reports  cited  in  the  section  above  was  the  major  factor  in 
users’  dissatisfaction  with  the  on-scene  information  provided.  Further,  there  was  no  capability 
for  two-way  query  and  response  against  the  LEIS  II  database,  which  was  one  of  the  primary  types 
of  information  users  wanted  access  to. 

The  remainder  of  this  section  presents  a  more  in-depth  discussion  of  the  research  results. 
Complete  raw  results  can  be  found  in  Appendix  A. 

5.1  Objective  Metrics 

This  section  presents  the  experiment  results.  Benefits  they  point  to  are  discussed  in  the  Benefits 
Analysis  section. 

5.1.1  Experiment  Results 

5. 1.1.1  Experiment!:  Time  Study 

5. 1. 1. 1. 1  Experiment  1  Results 

The  data  collected  in  the  pre-OIS  observation  weekend  varied  very  widely,  with  average 
transaction  times  reported  fluctuating  from  seconds  to  minutes.  The  consensus  of  the  observers 
was  that  even  with  the  high  observation  coverage  achieved,  the  resulting  data  were  suspect.  They 
reported  that  the  granularity  of  the  information  being  handled  was  too  fine  for  them  to  accurately 
record  the  details  required.  Put  differently,  the  average  transaction  time  is  short,  and  the 
transaction  volume  is  high.  Because  of  these  limitations,  the  evaluation  team  concluded  it  was 
infeasible  to  achieve  a  statistically  valid  comparison  between  pre-  and  post-OIS  times.  The  post- 
OIS  observation  was  therefore  canceled. 

5. 1.1. 1.2  Experiment  1  Analysis 

Interviews  with  command  center  personnel  and  the  Giroup  Commander  indicate  that  the  time 
spent  on  information  handling  during  operations  is  high.  There  is  a  significant  amount  of 
redundant  briefing,  wherein  a  command  center  watchstander  relays  the  same  information  by  voice 
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circuits  to  several  different  units.  This  occurs  both  down  the  chain  of  command,  to  resources 
being  tasked,  and  up  the  chain,  in  providing  briefings  both  inside  the  unit  and  in  parent  commands. 
If  the  briefing  information  were  available  from  OIS,  it  would  free  up  a  significant  amount  of 
watchstander  time.  The  value  of  the  time  fi-eed  up  in  this  manner  is  potentially  enormous,  since 
any  delay  in  relaying  information  during  a  case  can  significantly  impact  actions  taken  by  resources. 
This  can  make  the  difference  between  success  or  failure  of  the  case. 

5. 1.1. 2  Experiment  2:  Report  Preparation  Time 

5.1. 1.2.1  Experiment  2  Results 

In  the  group  providing  baseline  data  collection,  282  samples  were  taken  involving  SAR  cases 
(SARMIS/DES)  and  52  involving  boardings  (52  boardings  reported  in  26  SEER  messages). 
During  the  OIS  testbed,  31  samples  involving  Law  Enforcement  boardings  were  collected,  which 
was  found  to  be  an  adequate  sample  size.  However,  only  1 1  samples  were  taken  involving  SAR 
cases,  which  was  an  insufficient  sample  size  for  achieving  statistical  significance.  Therefore,  a 
controlled  experiment  was  designed. 

Two  non-rated  personnel  from  a  Station  which  had  been  involved  in  the  testbed  were  selected  to 
participate  in  the  test  They  were  chosen  because  they  had  been  assigned  as  communications 
watchstanders  during  the  testbed,  and  were  therefore  typical  users  of  the  shoreside  system.  49 
SAR  cases  were  chosen  at  random  from  OIS  for  them  to  re-validate.  The  cases  were  actual  ones 
which  had  been  prosecuted  and  entered  into  OIS  during  the  testbed.  They  were  “de-validated”  by 
the  tester,  by  deleting  40  data  elements  from  each  case.  Data  elements  deleted  were  typical  of 
those  which  would  not  normally  be  populated  at  the  end  of  the  case. 

For  LE  data,  OIS  reduced  data  entry  time  fi-om  an  average  of  12.2  minutes  per  boarding  to  an 
average  of  5.1  minutes  per  boarding,  a  savings  of  7.1  minutes.  For  SAR  data,  OIS  reduced  data 
entry  time  from  an  average  of  11.7  minutes  per  SAR  case  to  an  average  of  4.5  minutes  per  SAR 
case,  a  savings  of  7.2  minutes. 

5.1. 1.2.2  Experiment  2  Analysis 

The  results  of  experiment  2  indicate  that  OIS  saved  a  significant  percentage  of  user  time  by 
eliminating  the  requirement  to  manually  enter  the  data  in  other  systems  after  operations.  Table  2 
and  Table  3  summarize  the  results  of  the  report  time  study,  including  sample  sizes,  means,  and 
standard  deviations.  A  t-test  was  applied,  and  found  that  the  results  are  statistically  significant. 
The  strength  of  association  is  high. 

The  results  of  this  experiment  indicate  a  substantial  time  savings  would  accrue  to  the  Coast  Guard 
as  a  result  of  implementing  OIS.  For  every  Search  and  Rescue  case,  SARMIS  requires  a  Unit 
Report.  The  results  in  Table  2  indicate  a  savings  of  7.2  minutes,  or  62%,  each  time  a  Unit  Report 
is  filed.  Similarly,  Table  3  indicates  a  savings  of  7.1  minutes,  or  58%,  in  documenting  each  LE 
Boarding  compared  to  using  the  SEER  system.  Both  savings  are  substantial,  and  were  achieved 
with  a  proof  of  concept  system,  not  a  fully-featured  system.  Numerous  suggestions  for 
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improveinent  were  received  from  field  users,  which  would  enable  even  more  substantial 
improvements. . 


Table 

2:  Statistical  comparison  of  SAR 

OIS.  Data  indicate 

info  reporting  time,  pre¬ 
time  in  minutes . 

and  post- 

Unit 

Pre-OIS  SAR 

Pre-OIS  SAR 

Pre-OIS  SAR 

Post-OIS  SAR 

Post-OIS  SAR 

Post-OIS  SAR 

Case  Count 

Case  Mean  Time 

Case  Time  SD 

Case  Count 

Case  Mean  Time 

Case  Time  SD 

1 

6 

10.0 

0.0 

- 

- 

- 

2 

242 

11.6 

2.3 

- 

- 

- 

3 

10 

16.0 

4.4 

- 

- 

- 

4 

24 

10.7 

1.5 

- 

- 

- 

S 

« 

- 

- 

49 

4.5 

1.8 

ALL 

282 

11.7 

2.4 

49 

4.5 

1.8 

Table  3:  Statistical  comparison  of  LE  info  reporting  time,  pre  and  post  OIS. 

Data  indicate  time  in  minutes. 

“  Pre-OIS  Post-OIS 


Unit 

SEER  Msg 
Count 

Boarding 

Count 

SEER  Msg 
Mean  Time 

Boardings 
per  SEER 

Mean  SEER 
Time  per 
Boarding 

Boarding 
Time  SD 

Boarding 

Count 

Boarding 
Mean  Time 

Boarding 
Time  SD 

1 

5 

8 

21.4 

1.6 

13.4 

- 

- 

- 

- 

2 

11 

22 

23.3 

2.0 

11.6 

- 

- 

- 

- 

3 

10 

22 

24.1 

2.2 

11.0 

- 

- 

- 

- 

4 

- 

- 

- 

- 

- 

31 

5.1 

2.7 

All 

26 

52 

23.2 

2.0 

12.2 

5.7 

31 

5.1 

2.7 

5. 1.1.3  Experiments:  Report  Completeness 

5. 1.1. 3.1  Experiment  3  Results 

The  testers  analyzed  each  of  20  paper  SAR  case  folders  selected  at  random  to  determine  which 
data  elements  were  missing.  Of  the  20  case  folders  sampled,  10  were  incomplete.  68  total  data 
elements  were  missing.  On  average,  for  cases  that  were  missing  data,  6.8  data  elements  were 
missing.  For  the  total  population  of  cases,  an  average  of  3.4  data  elements  were  missing. 

A  typical  SARMIS  entry  consists  of  about  60  mandatory  data  elements,  and  another  30-50  which 
are  optional  or  may  be  required  depending  on  the  nature  of  the  incident.  The  detailed  results  may 
be  found  in  Appendix  A. 

5.1. 1.3.2  Experiment  3  Analysis 

A  chi-square  test  was  applied,  and  found  x"=485,  df=l,  and  p<10-’“.  This  indicates  a  strong 
likelihood  that  a  high  percentage  of  case  folders  in  the  Coast  Guard  are  incomplete. 
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The  business  value  to  the  Coast  Guard  of  missing  data  in  typical  case  folders  is  normally  not  high; 
however,  in  certain  instances  it  would  be  critical.  For  instance,  in  any  case  where  lives  were  lost 
or  property  was  damaged,  incomplete  data  could  jeopardize  the  Coast  Guard’s  success  in  a  court 
case.  In  such  cases,  personnel  are  likely  to  take  more  care  to  ensure  quality  documentation. 
However,  countering  these  efforts  is  the  fact  that  these  cases  are  by  their  nature  more  complex,  so 
the  potential  for  missing  information  is  substantially  higher. 

The  most  vital  cause  for  concern  is  not  that  data  may  be  missing  at  case  conclusion,  however,  but 
that  information  received  by  one  Coast  Guard  member  during  the  case  may  not  be  recorded  and 
shared  with  all  others  involved  in  the  case.  This  lack  of  information  could  substantially  change  the 
nature  of  the  response,  and  therefore  affect  the  results  of  the  search.  The  OIS  distributed 
database  approach  minimizes  the  chances  of  such  an  omission,  by  ensuring  that  all  parties  have 
access  to  the  critical  information  while  the  case  is  in  progress. 

This  experiment  only  examined  completeness  of  case  data,  not  accuracy.  Accuracy  is  addressed 
in  the  surveys. 

5.2  Subjective  Metrics 

This  section  analyzes  the  surveys  completed  by  users  near  the  conclusion  of  the  OIS  Phase  I 
testbed,  as  well  as  the  subsequent  interviews  and  workshop  results.  The  results  indicate  a  strong 
consensus  that  the  OIS  concept  is  sound,  and  'will  be  valuable  to  users  once  the  system  is  fully 
developed.  They  also  clearly  indicate  that  the  technical  deficiencies  and  features  not  implemented 
in  the  Phase  I  testbed  system  were  strong  negative  motivates  for  users.  This  paradoxical  situation 
is  best  embodied  in  an  analogy  by  the  Group  Commander;  “The  wheel  is  round.  We  had  a 
number  of  flat  tires  along  the  way,  but  the  value  of  the  concepts  was  clear  throughout  .” 

5.2.1  Analysis  of  Command  and  Control  Survey  Responses 

As  a  general  rule,  the  Group  Command  Center  Controllers  rarely  used  OIS.  While  this  was  a 
major  disappointment,  the  reason  is  found  in  the  fact  that  the  testbed  system  did  not  provide  them 
with  any  additional  capability.  The  classic  command  and  control  cycle  is  to  receive  information, 
analyze  it,  decide,  and  act.  Unreliable  OIS  communications  reduced  the  reliability  of  the  “receive” 
aspect  of  the  cycle  to  about  90%,  and  the  system  did  not  provide  feedback  regarding  success  or 
failure  of  communications.  The  testbed  also  did  not  provide  adequate  tools  to  support  the 
“analyze”  aspect  of  the  cycle  and,  in  fact,  added  confusion  because  new  and  old  case  information 
was  not  distinguished.  Finally,  the  OIS  testbed  did  not  provide  a  means  to  communicate  an  action 
plan  or  to  issue  a  tasking  to  operational  resources.  In  conclusion,  the  OIS  proof-of-concept  failed 
to  adequately  support  nearly  all  of  the  Group  Command  Center  Controller  requirements. 

Despite  the  shortcomings  cited  above,  the  Phase  One  testbed  did  provide  substantial  C^  benefits  in 
certain  areas.  During  one  major  search  involving  all  six  Group  UTBs  over  several  days,  the 
Group  Commander  was  able  to  watch  the  search  unfold  on  the  screen  in  the  command  center  by 
simply  walking  in  and  observing.  He  did  not  have  to  disturb  the  command  center  watch,  which 
was  immersed  in  handling  the  case.  Most  significantly,  he  saved  a  resource  and  eliminated  an 
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information  choke  point  by  choosing  not  to  deploy  an  on  scene  commander  (OSC).  Normally,  in 
such  a  search  he  would  have  deployed  CGC  BOLLARD,  a  65  foot  icebreaking  tug,  to  that  role. 

The  automated  communications  in  OIS,  had  they  been  reliable,  would  have  provided  tremendous 
value  to  command  center  personnel.  This  benefit  grows  exponentially  as  each  additional  unit  or 
resource  is  added  to  a  case,  since  the  command  center  watch  is  the  information  broker  for  a 
mission.  If  they  have  tools  that  improve  the  quality  and  speed  of  information  dissemination  during 
a  multi-unit  case,  they  can  spend  more  time  planning  the  response  and  less  time  communicating 

those  plans. 

Despite  the  problems  stemming  from  the  implementation  flaws,  interviews  with  the  Group 
Commander,  Operations  Officer,  and  Senior  Duty  Officer  revealed  tremendous  confidence  that 
the  command  and  control  functionality  would  provide  substantial  process  improvements.  In  fact, 
the  Group  Commander  felt  that  it  would  enable  a  centralized  dispatch  operational  paradigm,  in 
which  the  Group  watchstanders  handled  all  cases  throughout  the  group.  This  would  lower 
workload  on  the  stations  and  eliminate  another  layer  of  information  flow  during  operations, 
creating  further  process  improvements.  He  sees  this  concept  as  a  critical  enabler  for  successful 
employment  of  the  Norwegian  Crewing  Concept. 

To  summarize  the  Group  Commander’s  assessment  of  the  command  and  control  benefits:  the 
geographical  plot  afforded  him  a  situational  awareness  of  operations  not  previously  available. 
The  geographic  display  provided  an  overview  of  the  entire  AOR  with  tools  for  determining 
ranges,  bearings,  locations,  and  other  vital  operational  information.  In  addition  to  having  a 
display  of  all  landmasses  and  fixed  assets,  he  and  his  Operations  Duty  Officers  could  track 
operational  resource  locations  effortlessly  by  monitoring  their  automatic  position  reports  display 
on  the  electronic  chart.  He  could  exercise  command  and  control  of  a  case  far  more  effectively 
than  with  grease  pencil  renderings.  The  automated  generation  of  draft  SITREPs  reduced  the 
amount  of  time  that  operational  personnel  had  to  spend  on  during-the-case  reporting  of  case 
information.  The  database  of  unit  case  information  would  have  been  extremely  powerful  had  it 
provided  solid  queries  and  reports  to  give  him  access  to  the  information. 


5.2.2  Analysis  of  Operational  Reporting  Survey  Responses 

The  Operational  Reporting  Surveys  indicated  that  although  the  Phase  One  system  saved  time  in 
documenting  cases,  it  still  had  room  for  improvement.  Perhaps  the  biggest  complaint  was  that 
OIS  “required  too  much  data.”  In  point  of  fact,  the  converse  was  true:  the  Validation  feature 
ensured  that  OIS  only  required  the  bare  minimum  of  data.  However,  the  elegance  of  that  feature 
was  lost  on  users  who  had  to  navigate  through  several  screens  in  order  to  enter  missing  data.  OIS 
offered  a  large  number  of  optional  data  elements,  but  ones  which  may  at  times  be  required  by 
external  systems  so  had  to  be  available.  These  were  not  required  by  OIS  in  most  instances,  but 
their  very  presence  in  the  data  entry  screens  caused  user  perceptions  of  too  many  required  entries. 

Follow-on  interviews  with  users  yielded  the  concept  of  “smart  checklists,”  which  should  improve 
on  that  situation  dramatically.  The  checklists  envisioned  would  be  based  on  those  used  in 
command  centers,  and  would  be  the  primary  data  entry  interface  with  OIS.  One  scrollable 
window  would  incorporate  critical  elements  of  location  information,  vessel  description,  person 
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information,  and  sortie  dispatch  and  tasking.  It  would  also  allow  users  to  select  any  individual 
entry  and  generate  a  corresponding  chrono  log  entry,  complete  with  their  user  ID  and  the  time. 
The  system  would  store  the  data  from  these  checklists  in  the  appropriate  database  tables,  but  the 
user  would  not  have  to  navigate  through  multiple  screens.  Checklists  would  contain  only  the  vital 
information,  not  the  “nice-to-have”  pieces  of  additional  information,  so  the  system  would  appear 
simpler.  But  the  user  would  retain  the  option  of  adding  greater  detail  by  going  to  the  vessel 
screen,  for  instance,  to  enter  or  read  discretionary  information. 

The  second  most  common  complaint  was  that  OIS  required  users  to  “make  up”  responses.  This 
complaint  stemmed  almost  entirely  from  two  data  elements  which  were  implemented  poorly  in  the 
Phase  One  system:  Person  date  of  birth,  and  Reason  Search  Suspended.  Both  of  these  were 
required  by  the  Validation  routine  in  a  substantial  number  of  cases,  and  caused  strong  negative 
perception.  The  design  which  called  for  them  to  be  implemented  in  this  fashion  was  short-sighted. 
Person  date  of  birth,  for  instance,  was  mandatory  as  a  means  of  differentiating  between  people 
who  may  be  share  the  same  name.  However,  the  Privacy  Act  implications  for  OIS  indicate  that  it 
will  be  unlikely  for  users  to  have  query  and  reporting  capability  on  people  across  multiple  cases, 
this  is  unnecessary.  Designers  can  simply  assign  unique  numbers  to  each  person  within  the  same 
situation. 

5.2.3  Analysis  of  On-Scene  Information  Survey  Responses 

The  survey  responses  regarding  on-scene  information  were  strongly  negative.  Most  typical  was 
the  user  who  said,  ‘Why  use  a  computer?  I  can  talk  faster  than  I  can  type!”  But  these  responses 
uniformly  focused  on  outgoing  communications,  which  implies  data  entry.  The  Phase  One  mobile 
system  did  not  provide  any  query  or  reporting  capability  whatsoever;  if  a  user  wanted  to  find  out 
case  status,  s/he  had  to  navigate  through  the  data  entry  screens  to  locate  the  desired  information. 
This,  coupled  with  the  lack  of  reliability  in  OIS  Phase  I  communications,  meant  that  OIS  did  not 
support  their  information  needs  well.  However,  when  analysts  described  possibilities  for 
improved  reliability  and  reports,  users  felt  that  it  would  be  valuable. 

It  is  clear  that  a  data  system  will  not  replace  voice  communications  completely.  However,  several 
users  envisioned  being  able  to  rely  on  voice  communications  for  the  important  task  of  exception 
reporting,  or  discussing  only  those  aspects  of  the  case  which  seem  anomalistic.  By  adopting  this 
paradigm,  voice  communication  requirements  placed  on  the  boat  coxswain  could  be  greatly 
reduced.  This  would  remove  the  time  dependency  which  requires  that  the  shore  watchstander  and 
a  boat  crewmember  both  be  available  for  a  conversation  at  the  same  instant.  Thus,  it  would  allow 
the  coxswain  to  review  the  information  when  it  is  operationally  safe  and  convenient,  and  avoid 
being  interrupted  during  critical  evolutions  by  voice  radio  calls.  It  would  also  relieve  the 
coxswain  of  the  need  to  visit  the  operations  center  to  gather  mission  information  before  getting 
underway,  which  would  be  a  significant  time-saver  at  a  vital  juncture  early  in  the  case. 

Finally,  secure  data  transmission  provides  for  the  most  “silent”  means  of  coordinating  operations 
available.  The  existing  voice  circuits  are  protected  at  the  DES  level,  but  listeners  can  still  tell  that 
a  transmission  is  occurring,  and  the  direction  from  which  it  is  coming.  Data  is  transmitted  in 
bursts,  much  more  rapidly  than  voice;  it  typically  took  less  than  five  seconds  to  transmit  an  entire 
Situation  record  in  the  Phase  One  testbed. 
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5.2.4  Analysis  of  Pen-Based  Computer  Survey  Responses 

Survey  responses  strongly  indicated  dislike  for  the  pen-based  computer.  There  were  several 
significant  shortcomings  of  the  pen-based  computer  equipment,  and  of  the  mobile  application 
software,  which  account  for  a  large  portion  of  the  disfavor.  These  are. 

♦  The  pen-based  computer  was  far  too  slow.  It  took  1 1  seconds  to  load  the 
vessel  or  person  screens.  This  seemed  like  an  eternity  to  users;  some  estimated 
it  at  over  a  minute. 

♦  The  computer  was  not  rugged  enough,  nor  waterproof.  All  six  survived  their 
eight  months  in  the  field,  but  only  by  being  “babied.”  Field  personnel  expect 
their  equipment  to  stand  up  to  the  harsh  environment  in  which  they  work. 

Portable  computers  will  need  to  be  capable  of  withstanding  repeated  drops 
from  at  least  four  feet,  and  must  feel  solid  enough  that  users  believe  that  they 
can.  They  must  also  be  completely  waterproof,  but  yet  provide  easy  access  to 
connectors  when  needed. 

♦  The  computer’s  battery  life  was  deemed  unsatisfactory.  Actually,  battery  life 
was  over  two  hours  when  users  paid  careful  attention  to  keeping  batteries 
charged  and  avoiding  the  effects  of  battery  “memory”  common  to  Nickel 
Cadmium  rechargeables.  This  is  something  users  shouldn’t  have  to  pay 
attention  to,  however.  Longer  life,  easy  charging  aboard  the  boat,  batteries 
which  don’t  exhibit  memory  effect,  and  easy-to-read  indicators  of  battery 
status  are  all  critical  to  successful  use  of  portable  battery-powered  devices. 

♦  Users  reported  data  loss  on  a  handful  of  occasions.  This  completely  eliminated 
trust. 

♦  The  mobile  software  forced  users  to  save  their  work  manually,  instead  of 
saving  it  automatically  like  the  shore  system. 

♦  The  mobile  software  required  users  to  perform  several  steps  to  transmit  and 
receive  data,  and  did  not  notify  users  when  new  data  was  received. 

♦  The  mobile  software  did  not  provide  any  reports.  The  only  way  to  find  case 
information  was  to  navigate  through  the  screens. 

♦  The  mobile  software  forced  users  to  change  screens  several  times  to  enter  the 
data  required  for  a  typical  boarding.  This,  coupled  with  the  computer’s  slow 
response,  made  them  feel  very  awkward  at  certain  points  during  a  boarding. 

5. 2  4. 1  Impacts  on  Situational  Awareness 

Clearly  there  are  more  than  enough  deficiencies  here  to  explain  user  dissatisfaction.  However, 
when  questioned  during  interviews  and  in  workshops,  most  users  said  that  even  if  all  these 
problems  were  solved,  they  were  still  reluctant  to  espouse  the  concept  of  using  a  pen-based 
computer  during  a  boarding.  These  users  felt  that  even  if  the  bugs  were  worked  out,  they  would 
be  more  comfortable  remaining  with  paper,  and  entering  a  report  later.  A  much  smaller  group  of 
users  felt  that  using  a  pen-based  computer  would  be  a  significant  improvement  to  the  boarding 
process,  because  of  the  potential  for  speed  increases  and  decreased  workload.  Interestingly,  both 
sides  of  this  debate  were  concerned  primarily  with  Boarding  Officer  safety.  The  next  two 
paragraphs  summarize  their  key  points. 
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Over  80%  of  Phase  One  users  felt  uncomfortable  with  the  pen-based  computer,  as  evidenced  by 
the  numerous  suggestions  that  the  screens  should  be  made  to  look  just  like  a  4100  form.  They 
reported  that  they  had  to  focus  more  attention  on  the  computer  than  on  paper  4100  forms.  This 
contributed  to  a  feeling  of  tunnel  vision,  or  a  decrease  in  situational  awareness.  Also,  it  took  five 
to  ten  minutes  longer  to  do  a  boarding  using  the  pen-based  computer  than  with  paper,  even  after 
users  had  conducted  a  number  of  boardings.  Although  this  was  due  to  the  deficiencies  mentioned 
earlier,  it  was  clearly  unsatisfactory. 

A  few  users  did  feel  comfortable  with  the  pen-based  computer,  despite  the  testbed  system 
deficiencies.  They  reported  that  because  of  the  easy-to-use  picklists,  they  could  work  just  as 
easily  as  with  paper.  However,  even  in  this  group,  none  reported  being  able  to  work  faster  than 
with  paper.  There  were  a  large  number  of  user  suggestions  and  technical  evaluation  points  which 
would  improve  the  speed  of  the  computer  application  substantially,  almost  certainly  making  the 
process  faster  than  with  paper.  These  users  pointed  out  that  with  innovative  use  of  the 
technology,  the  process  could  be  speeded  up  tremendously.  Consider  retail  cash  registers:  by 
scanning  bar  coded  information  from  products,  stores  have  eliminated  errors  and  cut  time.  This 
could  be  done  with  driver’s  licenses  and  vessel  registrations,  leaving  little  to  enter  except  violation 
data. 

If  there  is  less  data  to  enter,  it  would  seem  to  follow  that  situational  awareness  should  improve. 
However,  human  perceptions  of  computers  rarely  follow  logic  so  simply.  The  amount  of 
dissatisfaction  introduced  by  the  deficiencies  listed  above  made  it  impossible  to  isolate  the  variable 
which  was  of  primary  concern,  the  effect  on  situational  awareness.  It  appears  that  there  is  strong 
potential  for  process  improvement,  and  we  recommend  that  the  Coast  Guard  do  further  human 
factors  testing  using  a  technically  improved  mobile  platform.  However,  based  solely  on  the 
results  of  the  Phase  One  testbed,  it  would  clearly  not  be  prudent  to  implement  use  of  pen-based 
computers  Coast  Guard-wide  for  data  capture  during  boardings. 

5, 2. 4. 2  Other  impacts  of  pen-based  computer  use 

5. 2. 4. 2. 1  Decision  Support 

The  Phase  One  testbed  included  a  small  Decision  Support  (DSS)  module,  designed  to  test  the 
concept  of  DSS  for  field  computer  users.  By  tapping  a  button,  users  could  obtain  detailed 
reference  information  about  recreational  boating  safety  (RBS)  equipment  requirements  depending 
on  boat  size  and  type.  This  module  was  developed  as  a  Cadet  project  at  the  Coast  Guard 
Academy,  and  was  not  integrated  into  the  rest  of  the  pen-based  system  for  the  testbed.  However, 
user  trials  of  the  DSS  module  were  conducted  separately.  Their  response  was  generally 
favorable.  The  testbed  system  implementation  was  too  slow  and  needed  user  interface 
enhancements,  but  showed  promise. 

Embedding  decision  support  in  the  portable  computer  is  the  factor  that  will  make  it  worth 
pursuing.  If  the  portable  computer  provides  source  data  capture  only,  it  is  an  expensive,  fragile 
clipboard.  However,  if  it  is  used  to  provide  information  on  demand,  references,  and  other  support 
that  enhances  the  boarding  officer’s  job  performance,  it  will  be  well  worth  it.  The  most  promising 
area  for  development  is  providing  regulation  references  and  enforcement  assistance.  For  instance. 
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fisheries  regulations  are  very  volatile,  changing  frequently  throughout  the  year  as  stock  sizes  are 
re-measured  and  quotas  re-allocated.  Distributing  this  information  electronically  and  having  a 
powerful  search  engine  for  accessing  the  regulation  of  choice  would  be  a  quantum  leap  forward  in 
the  ability  of  our  boarding  officers  to  enforce  these  complex  regulations.  Commercial  Fishing 
Vessel  Safety,  Immigration  laws,  and  Zero  Tolerance  procedures  are  all  examples  of  regulatory 
areas  in  which  field  personnel  could  use  improved  information  tools.  This  would  raise  the  level  of 
performance  across  the  board.  By  providing  this  information  in  easily  accessible  and  updatable 
form,  policy-makers  can  also  improve  the  timeliness  of  policy  updates. 

Computer  based  training  is  closely  related  to  this  topic.  By  embedding  training  modules  into  the 
system,  program  managers  can  provide  high  quality  recurrent  training  without  the  high  cost  of 
either  bringing  people  into  a  resident  school  environment  or  providing  touring  experts  to  the  field. 


5. 2. 4. 2. 2  Functional  Design 

The  mobile  system  software  was  purposefully  designed  to  closely  mirror  the  shoreside  system 
software.  It  offered  all  the  cross-functionality  of  the  shoreside  system,  and  the  screens  were 
similar.  The  design  philosophy  at  work  was  to  push  the  envelope  of  cross-functionality,  and  have 
all  components  of  OIS  be  as  thoroughly  cross-functional  as  possible.  However,  while  this 
concept  works  well  in  a  command  center  environment  where  the  mission  at  hand  can  change  in  an 
instant,  it  was  not  as  well-suited  for  mobile  use.  The  pen-based  computer  was  used  almost 
exclusively  during  boardings,  so  the  SAR  portions  of  the  application  were  rarely  used.  They 
were,  however,  frequently  maligned  as  adding  unnecessary  complexity.  Further,  the  small  screen 
size  and  slow  processing  speed  of  the  pen-based  computer  made  it  less  well-suited  for  a  cross¬ 
functional  application  with  a  wide  variety  of  data  elements. 

Future  versions  of  portable  computer  software  should  be  optimized  for  individual  tasks,  not  for  a 
range  of  tasks.  However,  the  pen-based  computer  could  remain  as  the  platform  that  would  host 
multiple  different  job-specific  mobile  applications;  a  boarding  officer  module,  a  SAR  SRU 
module,  etc.  could  all  be  available  on  the  pen-based  computer,  and  could  share  data.  They  would 
simply  provide  different  function-based  sequences  and  methods  for  entering  and  retrieving  data. 
This  is  conceptually  similar  to  the  need  for  interactive  checklists  described  in  the  Command 
Center  analysis. 

5.2.5  Extensions  beyond  SAR  and  Law  Enforcement 

Group  Long  Island  Sound  is  also  a  Captain  of  the  Port  (COTP).  The  chief  of  port  operations  was 
very  interested  in  the  possibility  of  using  OIS  to  support  his  missions.  Even  though  the  Phase  One 
project  did  not  include  direct  support  for  port  operations  in  its  database  schema,  he  envisioned 
taking  the  pen-based  computer  out  with  crews  deployed  in  either  a  truck  or  a  boat,  to  provide 
better  communications  and  source  data  capture  in  chrono  notes  for  automated  POLREP 
generation.  This  highlights  the  fact  that  operational  scenarios  where  Coast  Guard  personnel  are 
deployed  to  perform  mobile  field  operations  supported  by  remote  command  and  control  are 
common  to  all  Coast  Guard  Operational  Programs.  Portable  computers  would  be  highly  useful  in 
oil  spill  and  hazardous  materials  incident  response,  commercial  vessel  inspection,  casualty 
investigation,  port  operations,  refugee  operations,  and  others. 
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6.  BENEFITS  ANALYSIS:  OIS  PHASE  I 

The  major  benefits  which  OIS  can  provide  to  the  Coast  Guard  lie  in  its  ability  to  enable  business 
process  reengineering,  and  leverage  our  assets  to  greater  advantage  for  mission  performance  and 
service  to  the  American  public.  The  Group/Station  OIS  Testbed  was  constrained  to  working 
within  the  existing  organizational  structure,  and  so  did  not  yield  any  empirical  data  defining  the 
extent  of  the  reengineering  possibilities.  But  interviews  conducted  with  the  Group  Commander 
and  his  Operations  staff  during  the  Testbed  revealed  high  confidence  that  the  Operational 
Information  System  could  allow  significant  improvement.  Several  flag  officers  who  visited  the 
testbed  similarly  indicated  support  for  the  potential  of  OIS.  Briefings  invariably  moved  rapidly 
from  the  testbed  system  as  built  to  the  possibilities  presented  by  a  widely  deployed,  robust  system. 
The  Commandant  and  Chief  of  Staff  reportedly  share  their  high  levels  of  interest. 

The  cross-functionality  inherent  in  the  Operational  Information  System  is  consistent  with  the 
farthest-reaching  recommendations  of  the  Coast  Guard’s  Strategic  Information  Resource  Planning 
process,  or  SIRMP.  It  would  improve  utilization  of  Information  Technology  resources,  by 
sharing  information  and  costs  between  programs,  providing  direct  support  for  the  Commandant’s 
eighth  strategic  goal,  to  “pursue  and  acquire  new  technologies  that  meet  field  commanders’  needs 
and  enhance  mission  performance.”  It  is  a  natural  fit  with  the  flag-level  study  teams  currently 
exploring  ways  to  streamline  Coast  Guard  operations  and  the  training  system.  These  teams  have 
the  challenge  of  supporting  the  Commandant’s  third  strategic  goal,  to  meet  the  mandate  to 
streamline  with  no  reduction  in  essential  services.  OIS  would  play  a  key  role  in  enabling  these 
visions. 

The  Group/Station  OIS  Testbed  emphasized  operational  reporting.  The  results  showed  that 
report  consolidation  and  elimination  would  save  field  personnel  valuable  time,  with  benefits 
totaling  roughly  a  million  dollars  per  year  fully  deployed.  However,  this  offsets  only  a  portion  of 
the  total  cost  of  OIS,  and  would  not  warrant  further  development  on  its  own  merits.  Further,  the 
benefits  of  report  reduction  are  not  capturable  in  the  budget,  because  the  average  benefit  was  on 
the  order  of  one  tenth  of  an  FTE  per  unit.  Another  significant  OIS  benefit  results  from  an 
improvement  in  search  effectiveness.  This  is  achieved  by  coupling  improved  search  precision  of 
individual  SRUs  with  improved  search  planning.  Yet  another  benefit,  and  the  only  one  of  these 
three  which  is  a  direct  cost  avoidance,  is  a  decrease  in  damage  from  small  boat  groundings 
because  of  improved  navigation  provided  by  the  Electronic  Chart  Systems.  This  is  typical  of  the 
benefits  OIS  offers  to  the  Coast  Guard.  Efficiency  gains  within  the  existing  organizational 
structure  would  be  valuable,  and  effectiveness  gains  could  be  substantial.  But  if  the  Coast  Guard 
deploys  OIS  within  the  existing  organization,  there  will  be  few  direct  cost  savings  or  avoidances, 
and  benefits  will  not  offset  system  costs.  OIS  both  enables  business  process  reengineering,  and 
requires  it  in  order  for  the  agency  to  realize  the  full  potential  benefits. 

This  chapter  begins  with  a  more  detailed  discussion  of  the  ways  in  which  OIS  would  provide  these 
opportunities  for  reengineering.  It  then  presents  further  details  of  the  benefits  measured  during 
the  Group/Station  Testbed,  and  summarized  in  the  previous  paragraph. 
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6.1  Command  AND  Control  Improvements 

By  providing  a  platform  to  integrate  several  systems  already  in  place  and  initiatives  already 
underway,  OIS  could  enable  the  Coast  Guard  to  improve  business  processes,  perform  assigned 
missions  'with  fewer  resources,  streamline  the  organization,  and  decrease  our  shoreside 
infrastructure.  The  situation  today  is  not  unlike  the  move  from  visual  communications  (or  none) 
to  voice  radio.  By  equipping  vessels  with  radios,  the  Coast  Guard  was  able  to  coordinate  them 
effectively  for  the  first  time,  shifting  from  a  large  number  of  independent  resources  to  a  smaller 
number  of  coordinated  resources,  the  sum  of  which  was  more  effective.  OIS  is  the  key  to  taking 
the  next  step,  enabling  the  Coast  Guard  to  coordinate  multi-unit  operations  even  more  effectively. 

The  last  two  decades  have  seen  steady  increases  in  the  frequency  of  coordinated  multi-unit 
operations,  especially  in  the  law  enforcement  and  marine  environmental  protection  mission  areas. 
The  task  of  actually  coordinating  these  operations  is  difficult  and  frequently  ineffective. 
Communications  are  cited  as  problem  areas  in  nearly  every  study  of  operations.  The  nature  of 
voice  communications  is  a  major  part  of  this  problem.  If  a  voice  circuit  fails  to  connect  or  is 
noisy,  the  field  user  must  either  go  without  communications  or  expend  considerable  effort  to  get  a 
small' amount  of  information  through.  If  a  data  circuit  fails  to  connect,  on  the  other  hand,  the 
computer  carries  out  the  retries  to  ensure  delivery. 

Newly  available  technologies  and  public  data  communication  services  allow  the  same  amount  of 
information  to  be  transmitted  in  data  form  much  faster  and  more  reliably  than  by  voice.  For 
instance,  an  OIS  Phase  I  datagram  representing  the  entire  case  folder  consisted  of  about  1,000 
bytes  (characters)  of  information,  and  could  be  transmitted  in  less  than  five  seconds.  This  same 
information  would  take  several  minutes  to  transmit  by  voice.  Because  of  the  time  savings,  the 
transmission  tvill  be  significantly  less  expensive  on  a  usage-sensitive  circuit. 

Replacing  voice  communications  with  data  provides  another  substantial  improvement  in 
operational  coordination.  Because  of  the  computer  processing  power  on  either  end,  data  can  be 
converted  into  information  for  the  user,  enabling  quicker  and  better  analysis  of  the  updates.  This 
information  can  be  used  by  the  recipient  at  the  recipient’s  own  convenience,  instead  of  when  the 
originator  is  available.  This  is  an  important  enhancement  for  both  effectiveness  and  safety. 
Helicopter  pilots  involved  in  the  Phase  II  user  workshops  placed  a  very  high  value  on  this  feature 
of  data  communications,  since  they  allow  the  pilots  to  conduct  sensitive  evolutions  such  as  a  hoist 
or  hover  without  being  interrupted  by  a  voice  radio  call.  Personnel  aboard  mobile  resources 
would  now  be  able  to  view  information  when  they  are  ready  for  it,  not  when  it  is  forced  upon 
them  by  an  external  source. 

Remote  dependent  surveillance  system  (RDSS),  or  resource  tracking,  provides  another  significant 
command  and  control  improvement.  The  operational  commander  can  literally  watch  an  evolution 
unfold  on  the  screen  in  the  command  center.  This  eliminates  the  need  to  call  units  for  frequent 
updates,  which  require  the  simultaneous  attention  of  personnel  onboard  the  mobile  resources  and 
in  the  command  center.  Most  significantly,  it  can  actually  save  dedicating  a  resource  to  serve 
solely  as  On  Scene  Commander.  The  resource  that  was  used  for  that  duty  can  be  dedicated 
strictly  to  searching,  or  can  be  kept  in  port,  ready  for  another  mission.  In  the  case  of  sustained 
coordinated  operations,  such  as  the  Commander  Task  Unit  (CTU)  missions  being  performed  in 
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several  Districts,  the  OSC  or  CTU  would  continue  to  be  used,  but  would  have  much  better 
control  of  geographically  dispersed  units. 

It  is  clear  that  a  data  system  cannot  replace  voice  communications  completely.  However,  OIS 
would  provide  operational  personnel  the  opportunity  to  rely  on  voice  communications  for  the 
important  task  of  exception  reporting,  or  discussing  only  those  aspects  of  the  case  which  seem 
anomalistic. 

Finally,  secure  data  transmission  provides  for  the  most  “silent”  means  of  coordinating  operations 
available.  The  existing  voice  circuits  are  protected  at  the  DES  level,  but  listeners  can  still  tell  that 
a  transmission  is  occurring,  and  the  direction  from  which  it  is  coming.  Data  is  transmitted  in 
bursts,  much  more  rapidly  than  voice;  these  bursts  are  harder  to  detect  than  steady  voice 
transmissions. 

6.2  Business  Process  Reengineering 

The  combination  of  these  improvements  can  have  dramatic  effects  for  the  Coast  Guard.  The 
Group  Commander  in  the  Phase  One  Testbed  felt  that  by  combining  OIS  and  the  Norwegian 
Crewing  Concept,  he  could  easily  handle  the  existing  workload  with  five  Utility  Boats  instead  of 
the  six  currently  assigned  to  the  Group.  They  could  be  based  in  one  or  two  locations  in  Long 
Island  Sound  instead  of  three,  and  be  much  more  flexibly  staged  for  scheduled  events.  Group 
command  center  watchstanders  would  handle  all  cases  throughout  the  group.  Personnel 
reductions  would  be  possible,  both  in  communications  watchstanders  and  support  personnel. 
Shoreside  infrastructure  would  be  reduced. 

There  are  obviously  many  details  that  must  be  worked  out  if  such  an  arrangement  is  to  be 
pursued.  But  the  key  is  that  it  is  now  clearly  feasible,  through  a  combination  of  OIS,  innovative 
resource  crewing  concepts,  and  other  concepts  that  have  been  discussed  during  the  recent 
streamlining  and  training  infrastructure  studies. 

6.3  Decision  Support 

Embedding  Decision  Support  Systems  (DSS)  in  OIS  computers  will  make  a  large  improvement  in 
operational  performance.  The  computers  at  each  location  can  provide  information  on  demand, 
references,  and  recommendations.  These  systems  can  be  updated  more  easily  and  quickly  than 
policy  updates  distributed  on  paper,  and  less  expensively.  When  a  user  is  involved  in  an  unusual 
incident,  the  reference  is  more  readily  available,  and  can  be  searched  for  exact  details. 

An  important  part  of  the  benefit  of  DSS  is  its  ability  to  provide  the  user  with  “just-in-time” 
information.  This  reduces  the  need  to  store  infrequently  used  information  in  the  user’s  brain,  in 
the  same  way  that  just-in-time  manufacturing  reduces  a  company’s  need  to  store  parts  in 
warehouses.  Information  is  available  to  the  user  in  an  easily  retrievable  format  when  it  is  needed. 
An  example  of  this  potential  occurred  during  the  training  period  just  before  the  beginning  of  the 
Group/Station  Testbed.  A  UTB  crew  discovered  a  small  amount  of  marijuana  during  a  boarding, 
and  conducted  a  Zero  Tolerance  seizure.  There  are  well-defined  policies  governing  this  type  of 
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seizure,  but  few  are  conducted,  so  users  were  not  immediately  familiar  with  the  necessary  steps, 
Shoreside  personnel  spent  a  substantial  amount  of  time  hunting  down  references.  They 
envisioned  the  boarding  officer  being  able  to  access  the  references  and  detailed  step-by-step 
guidelines  right  on  the  portable  computer,  and  transmit  updates  to  the  shoreside  command  center 

easily. 

6.4  Reduced  Training  Requirements 

In  addition  to  the  improvements  described  in  the  previous  section,  DSS  could  provide  dramatic 
reductions  in  training  requirements.  The  Training  Infrastructure  Study  Team  is  examining  ways  in 
which  the  training  system  can  be  overhauled  to  provide  better  quality  training  at  lower  cost. 
Computer-based  training  (CBT)  embedded  within  the  Operational  Information  System  will 
support  this  effort,  allowing  training  to  be  provided  to  a  larger  number  of  personnel  at  lower  cost. 
There  are  two  primary  mechanisms  at  work  here.  First,  we  could  eliminate  training  on  tasks 
which  are  calculation-intensive.  Let  the  computer  do  the  calculations,  and  educate  the  human  on 
how  to  interpret  and  apply  the  results.  Second,  we  could  dramatically  reduce  training  on  len^hy 
rule-based  tasks.  In  both  cases,  the  machine  can  manipulate  information  and  present  it  in  a 
manner  suitable  for  making  the  critical  decisions. 

Eliminating  training  on  these  rote  tasks  could  cut  the  course  schedule  substantially.  However,  this 
should  not  be  interpreted  to  mean  that  DSS  can  eliminate  the  entire  time  allotted  to  these 
activities.  It  is  still  important  to  educate  the  person  about  the  meaning  of  the  tasks,  the  underlying 
concepts,  and  how  they  relate  to  the  overall  framework  of  the  job  being  performed.  As  an 
example,  including  DSS  and  CBT  for  search  planning  functions  could  enable  the  SAR  School  to 
eliminate  over  a  week  of  training  from  their  schedule,  and  focus  the  remaining  time  even  better  on 
education  of  the  students  about  the  concepts. 

CBT  can  also  prepare  students  for  resident  schools  before  they  arrive,  covering  prerequisite 
material  so  that  they  are  more  ready  to  learn  upon  arrival.  For  instance,  a  boarding  officer  module 
could  teach  boating  safety  regulations,  licensing  and  documentation  requirements,  and  actual  use 
of  the  form,  so  that  students  arrive  at  MLE  School  ready  for  education  about  the  concepts  of 
jurisdiction,  officer  safety  and  presence,  and  self-protection.  CBT  and  DSS  embedded  in  OIS 
could  reduce  resident  training  requirements,  a  major  benefit  to  the  units,  the  training  budget,  and 
the  Coast  Guard’s  “General  Detail”  or  personnel  over-allocated  for  training  purposes. 


6.5  BENEFITS  Quantified  During  Group/Station  Testbed 

The  remainder  of  this  chapter  quantifies  some  of  the  benefits  attributable  to  Coast  Guard-wide 
deployment  of  the  Operational  Information  System,  Phase  I.  Table  4  lists  the  major  features 
included,  and  is  the  basis  for  this  benefits  analysis. 

The  primary  functional  difference  between  Phase  I  and  Phase  II  of  the  OIS  R&D  projects  is  the 
additional  integration  of  Computer  Aided  Search  Planning  System  (CASP)  in  the  shoreside 
system.  The  primary  resource  difference  is  the  addition  of  Cutters,  Aircraft,  District  and  Area 
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command  centers.  This  would  involve  developing  an  additional  mobile  subsystem,  optimized  for 
aircraft  use.  Cutters  would  use  a  system  based  on  the  ones  in  shoreside  command  centers. 


Table  4:  Major  OIS  Phase  I  functions. 


Shoreside  Subsystem 

Utility  Boat  Subsystem 

I  Geographic  Information  System  (GIS)  to  integrate 
operational  information 

Electronic  Chart  System  to  improve  navigational  i 
accuracy  i 

Data  entry,  including  source  data  capture 
trequires  fast  response  for  use  during  ops) 

Source  data  capture,  during  SAR  and  boardings,  j 
via  pen-based  computer  i 

Data  (hstribution,  allowing  all  units  access  to 

I  shared  case  information,  and  resolving  conflicts 
between  updates 

Data  distribution 

i  Electronic  checklists  . 

Electronic  checklists 

l  Resource  and  facility  tracking  via  GIS 

Remote  Dependent  Surveillance  System  (RDSS)  | 
for  ops  and  position  reporting 

I  Vaiidaition  to  verify  completeness  and  accuracy  for 
i  external  system  export.  . 

Validation 

!  ^erationai  reports  consolidation  and  export  to 

I  external  systems  . 

Automatic  Report  Generation 

i  On-line  access  to  LEIS  H  information 

On-line  access  to  LEIS  II  information  I 

I  Eiectronic  tasking  to  resources  . 

Electronic  tasking  and  status  reporting 

i  integrated  Decisions  Aids 

Integrated  Decisions  Aids,  such  as  regulation  j 
references  on-line 

Table  5  summarizes  the  annual  and  life  cycle  benefits  attributable  to  the  Operational  Information 
System,  Phase  I.  Each  line  item  in  the  benefit  summary  is  discussed  in  detail  in  a  section  of  this 
chapter.  The  first  set  of  benefits  are  those  which  are  directly  quantifiable,  and  capturable  within 
the  Coast  Guard  budget  as  either  direct  cost  savings  or  cost  avoidances.  The  second  set  of 
benefits  are  quantified,  but  cannot  be  captured  within  the  Coast  Guard  budget.  For  instance, 
reports  reduction  will  save  our  field  personnel  from  working  overtime.  However,  since  military 
personnel  are  not  compensated  for  overtime  work,  this  does  not  present  a  benefit  that  can  be 
captured  in  the  budget.  It  is  likely  to  produce  long-term  benefits  such  as  better  retention  because 
of  improved  working  conditions,  reduced  health  care  cost  because  of  lowered  stress,  and  similar 
work-life  concerns. 
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Table  5:  OIS  Phase  I  benefit  smnmary. 


Benefit 

Type  Benefit  Description 

Monetizable  Benefits  (Direct  Cost  Avoidance  or  Savings) 

Avoidance  of  accidental  collisions  and  groundings 


Total  Life 
Annual  Cycle 

One-Time  Benefit  Benefit 

Benefit  ($M)  ($M)  ($M) 

$20  $20.0 


_ Subtotal,  Monetizable  Benefits  ($M) 

Non-Monetizable  Benefits  (Indirect  Cost  Avoidance  or  Benefits  to  Society  in  General) 
Report  Reduction 
Improved  Search  Accuracy 


$2.0 


$0.6 

$2.2 


$20.0 


$6.3 

$21.6 


6.5.1  Reduced  Groundings  Through  Navigational  Improvements 

The  Electronic  Chart  System  used  aboard  Utility  Boats  in  the  Phase  I  Testbed  was  a  solid  success 
with  users,  and  provides  clear  financial  benefits  in  direct  cost  avoidance  of  groundings  due  to  (a) 
navigation  error  or  (b)  high  coxswain  job  tasking  preventing  sufficient  time  to  navigate  manually. 

Coast  Guard  small  boats  operate  with  crews  of  three  or  four  personnel.  They  operate  nearly 
exclusively  in  coastal  and  piloting  waters,  with  high  mission  tasking  nearly  every  time  they  get 
underway.  Although  the  coxswain’s  primary  responsibility  is  the  safety  of  the  boat  and  crew,  the 
high  mission  tasking  frequently  prevents  formal  fixes;  the  coxswain  estimates  position  by  seaman’s 
eye  between  fixes,  while  all  other  hands  are  performing  an  evolution  for  which  s/he  is  the  leader. 

In  this  environment,  the  Coast  Guard  small  boat  sometimes  runs  aground,  suffering  varying 
damages.  G-N-1  estimated  that  total  small  boat  grounding  damages  over  a  five  year  period 
ending  in  1992  were  $38  million,  or  about  $8M  per  year.  Coxswains  and  Officers  in  Charge 
during  the  Phase  I  Testbed  estimated  that  over  50%  of  groundings  could  be  avoided  by  use  of 
Electronic  Chart  Systems.  That  equates  to  a  direct  cost  avoidance  of  over  $4M  per  year.  Since 
the  estimate  is  based  on  subjective  analysis,  not  empirical  data,  it  is  discounted  by  half  for  the 
benefit  calculation  below.  Even  conservatively,  this  OIS  benefit  would  save  some  $2M  per  year, 
as  shown  in  Table  6. 

Table  6:  Annual  benefit  from  reduced  groundings.  Phase  I. 


Annual  damages  resulting  from  groundings 
Estimated  reduction  in  grounding  rate  resulting 
from  ECS  use 

$8,000,000 

25% 

Estimated  Annual  Benefit 

$2,000,000 
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There  is  another  direct  benefit  to  using  Electronic  Chart  System  aboard  boats.  Currently,  the 
coxswain  spends  a  substantial  amount  of  time  performing  the  task  of  plotting  navigational  fixes, 
as  high  as  50%.  Electronic  Chart  Systems  will  return  almost  all  of  that  time  to  the  coxswain,  by 
enabling  the  coxswain  to  focus  on  analyzing  the  boat’s  position  and  situation  as  presented  on 
screen,  rather  than  plotting  it.  This  time  can  be  used  either  for  improved  crew  management  or  for 
analyzing  the  external  environment.  In  the  aviation  world,  this  is  referred  to  as  “head  outside  the 
cockpit”  time,  and  refers  to  the  need  to  avoid  focusing  attention  on  the  instruments  and  other 
equipment  inside  the  cockpit.  The  same  principle  applies  to  coxswains. 

6.5.2  Reports  Reduction 

Reports  reduction  was  one  of  the  primary  objectives  of  the  Phase  I  Testbed.  The  Small  Boat 
Station  Staffing  Study,  the  OIS  user  workshops,  and  numerous  other  studies  have  all  indicated 
that  this  is  an  area  of  significant  wasted  effort,  and  a  strongly  negative  motivator  for  the  Coast 
Guard’s  performance  oriented  field  personnel.  The  Research  Results  section  reported  that  several 
minutes  of  documentation  were  saved  by  OIS  after  the  end  of  each  operational  incident.  It  then 
quantified  the  benefits  for  the  two  reports  directly  tested,  SARMIS  and  LEIS  II.  While  those 
savings  alone  are  substantial,  they  represent  only  the  tip  of  the  iceberg  of  operational  reporting. 
They  can  be  extrapolated  to  the  many  other  reports  and  logs  that  field  personnel  maintain  during 
operations. 

The  results  of  this  extrapolation  are  displayed  in  Table  7.  First,  it  assumes  values  for  time  savings 
that  may  be  realized  by  consolidating  or  eliminating  each  report  or  log.  Since  no  empirical  data 
are  available,  this  estimate  is  extremely  conservative,  allowing  only  a  savings  of  one  or  two 
minutes  per  report.  The  three  major  departures  from  this  rule  are  SITREPs  and  POLREPs,  which 
are  assumed  to  take  an  average  of  30  minutes  each;  the  Abstract  of  Operations  Report,  assumed 
to  take  60  minutes  once  per  quarter;  and  the  MLE  Weekly  Feeder  Report,  assumed  to  take  10 
minutes  once  per  week.  Interviews  indicate  that  these  estimates  are  also  conservative.  The  MLE 
Weekly  Feeder  Report  is  not  a  title  used  uniformly  throughout  the  Coast  Guard;  it  is  used  only  in 
the  First  District.  However,  it  represents  a  general  category  of  reports  which  are  required  by 
operational  commanders  in  many  areas.  Some  places  call  it  a  SAR  Summary,  others  an 
Operational  Summary.  In  some  locales,  it  is  required  daily,  in  others  weekly  or  even  monthly. 
The  assumptions  here,  ten  minutes  per  unit  per  week,  are  on  the  low  end  of  the  scale. 

Table  7  then  estimates  the  number  of  reports  per  year  which  may  are  involved,  and  the  labor  rate 
of  the  pay  grade  that  would  typically  complete  each  report.  Finally,  it  calculates  the  annual 
benefit  for  each  of  the  reports.  It  is  likely  that  some  of  these  individual  estimates  may  be 
overstated,  and  others  understated.  However,  they  are  believed  to  be  quite  conservative  in  the 
aggregate,  and  representative  of  the  order  of  magnitude  of  the  monetary  value  associated  with 
doing  the  paperwork  after  the  mission  is  over. 
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Table  7 :  Annual  benefit 

of  operational 

reports 

reduction,  OIS 

Phase  I . 

Minutes 

saved 

Hours 

Benefit, 

per 

Reports 

saved 

Labor 

dollars  per 

Report  Type 

report 

per  year 

per  year 

Rate 

year 

SARMIS  entries 

7 

40,000 

4,800 

17 

$81,600 

SEER  Messages  (Boardings) 

7 

15,000 

1,625 

24 

$39,000 

SEER  Messages  (Sightings) 

2 

10,000 

333 

24 

$8,000 

Boarding  Report  (CG  4100) 

2 

15,000 

500 

24 

$12,000 

SITREPS  (10%  of  SAR  cases) 

30 

2,500 

1,250 

24 

$30,000 

Distress  checkoff  sheet 

0 

- 

17 

$0 

POLREPS 

30 

2,500 

1,250 

24 

$30,000 

Abstract  of  Operations  Rpt 

60 

6,000 

6,000 

24 

$144,000 

SAR  Case  Folder 

3 

40,000 

2,000 

17 

$34,000 

MLE  Weekly  Feeder  Reports 

10 

10,400 

1,733 

24 

$41,600 

Abbreviated  Radio  Log 

2 

40,000 

1,333 

17 

$22,667 

Chrono  log 

0 

- 

17 

$0 

Unit  Underway  Hours  log 

1 

70,000 

1,167 

17 

$19,833 

Weather  log 

0 

- 

17 

$0 

Training  log 

2 

280,000 

9,333 

17 

$158,667 

Auxiliary  Orders  log 

0 

- 

17 

$0 

SEER  log 

1 

15,000 

250 

17 

$4,250 

Totals 

31,575 

$625,617 

As  3,  point  of  compErison,  the  Small  Boat  Station  Staffing  Study  results  showed  that  Station 
personnel  spend  6.2%  of  their  80-hour  work  weeks  on  paperwork.  There  are  approximately 
4,000  people  at  Stations,  and  their  labor  rates  are  approximately  evenly  distributed  between  $17 
per  hour  and  $24  per  hour.  This  means  an  annual  payroll  of  about  $328  million.  6.2  %  of  this  is 
$20M.  If  10%  of  their  paperwork  time  (0.62%  of  total  time)  is  spent  on  operational  reporting, 
then  the  total  value  of  this  time  is  $2  million  annually.  Both  estimates  agree  within  a  factor  of 
two,  and  indicate  that  substantial  improvement  is  possible. 

While  no  individual  time  saving  is  especially  large,  the  cumulative  effect  is  a  substantial  monetary 
investment  in  report  writing.  The  quantifiable  benefit  is  not  large  compared  with  the  total  cost  of 
developing  the  Operational  Information  System.  However,  the  intangible  benefits  of  eliminating 
the  negative  motivation  that  results  fi-om  our  splintered  operational  reporting  paradigm  are 
substantial. 

6.5.3  Improved  Search  Precision 

The  Coast  Guard’s  Computer  Aided  Search  Planning  system  (CASP)  allows  command  center 
watchstanders  to  generate  search  patterns  automatically.  However,  these  patterns  must  be 
decomposed  into  descriptive  text  and  transmitted  to  Search  and  Rescue  Units  (SRUs)  by  voice  or 
text-based  methods,  then  re-plotted  or  entered  in  SRU  navigation  systems.  Finally,  the  SRU 
commander  must  manually  navigate  the  craft  through  the  search  pattern  and  report  results  back  to 
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the  command  center  for  effectiveness  calculations.  Using  OIS  to  integrate  GASP  into  the  actual 
search  execution  instead  of  stopping  at  the  planning  stage  would  create  significant  improvements 
in  search  performance.  It  would  also  make  even  more  substantial  improvements  in  analyzing 
searches  that  did  not  locate  the  targets,  and  in  planning  subsequent  searches. 

The  success  of  search  efforts  depends,  in  part,  on  the  navigational  precision  of  Search  &  Rescue 
Units  (SRUs).  For  a  variety  of  reasons,  the  performance  of  CG  resources  in  search  operations  is 
described  (from  a  strictly  theoretical  standpoint)  as  random.  By  improving  navigational  precision, 
the  Coast  Guard  could  make  dramatic  improvements  in  search  capabilities,  and  lower  costs.  Even 
more  important,  we  would  expect  to  save  more  lives  by  (a)  locating  victims  instead  of  not 
locating  them,  and  (b)  locating  them  sooner,  before  hypothermia  and  exposure  have  set  in.  The 
majority  of  this  benefit  would  accrue  to  Phase  II  resources,  predominantly  aircraft,  since  they  are 
the  search  platforms  of  choice  and  are  high  cost  resources.  Therefore,  the  detailed  discussion 
underlying  the  search  effectiveness  improvements  is  presented  in  the  Phase  II  benefits  analysis  in 
Appendix  F.  For  this  section  of  the  report,  suffice  it  to  say  that  by  improving  the  accuracy  of 
search  pattern  execution,  we  can  improve  our  search  effectiveness.  The  discussion  in  Appendix  F 
concludes  that  search  effectiveness  increases  by  50%  as  a  result  of  coupling  OIS  and  GASP. 
These  benefits  are  not  capturable  in  the  Goast  Guard  budget,  but  rather  prevent  us  from  having  to 
spend  additional  search  hours  to  achieve  the  same  level  of  effectiveness. 

6.6  Summary 

OIS  provides  the  Goast  Guard  with  a  tool  that  can  enable  substantial  business  change  and 
improvement.  Its  primary  benefits  lie  in  this  potential.  Investment  in  OIS  gives  program 
managers  many  opportunities  to  reduce  overall  costs  and  improve  service. 
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7.  OIS  PHASE  I  COST  ESTIMATE 


Cost  estimates  are  considered  Procurement  Sensitive  Information,  release  of  which  could  detract 
from  full  and  open  competition  in  future  acquisitions  involving  OIS.  Therefore,  this  chapter  has 
been  deleted  from  the  publicly  available  version  of  this  report. 
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8.  CONCLUSIONS  AND  RECOMMENDATIONS 
8.1  Conclusions 

The  Group/Station  Operational  Information  System  Testbed  was  highly  successful  at  meeting  the 
primary  Research  and  Development  objective,  to  evaluate  the  concept  of  an  integrated,  cross¬ 
functional,  distributed  data  system  that  links  Coast  Guard  command  centers  and  mobile  resources. 
However,  as  was  to  be  expected  in  a  high-risk  proof-of-concept  effort,  it  failed  to  meet  some  of 
its  technical  goals.  These  problems,  and  testbed  limitations,  made  it  impossible  to  measure 
empirically  the  major  benefits  of  OIS.  The  OIS  Phase  II  work  will  seek  to  eliminate  more  of  this 
uncertainty.  However,  the  results  of  the  Phase  One  Testbed  provide  valuable  lessons  learned  so 
that  future  development,  both  in  further  R&D  and  in  AC&I  development,  may  be  undertaken  with 
substantially  reduced  risk.  The  following  paragraphs  present  the  major  conclusions  drawn  from 
the  Group/Station  OIS  Testbed. 

We  conclude  it  is  technically  feasible  for  the  United  States  Coast  Guard  to  implement  the 
Operational  Information  System.  Further,  information  technology  has  matured  to  the  point  that 
the  Coast  Guard  can  now  implement  the  Operational  Information  System  cost-effectively.  Most 
underlying  technologies  are  well  developed,  with  none  posing  unacceptable  technical  risk.  The 
highest  risk  technological  areas  in  a  full-scale  deployment  are  distributed  database  technology,  and 
robust  packet-switched  satellite  communications. 

Redundant  data  entry  can  be  virtually  eliminated.  Automatic  transfer  of  information  from  OIS  to 
legacy  systems  such  as  SARMIS  and  LEIS  II  is  a  significant  time  saver,  allowing  greater  focus  on 
operations.  This  will  also  improve  the  work-life  balance  for  Coast  Guard  people. 

The  Operational  Information  System  is  a  critical  enabler  for  the  One  Port/One  Command  Center 
concept.  In  order  to  consolidate  functions  physically,  they  must  be  consolidated  logically.  If  the 
Coast  Guard  simply  houses  the  same  business  functions  in  a  single  room  without  changing  their 
component  work  processes,  the  total  workload  will  remain  unchanged,  and  the  same  level  of  staff 
will  be  required  to  support  them.  OIS  provides  the  cross-functional  information  infrastructure 
necessary  to  complete  the  logical  consolidation. 

OIS  will  increase  operational  commanders’  span  of  control  and  act  as  a  force  multiplier,  allowing 
the  agency  to  perform  assigned  missions  with  fewer  resources.  This  enables  organizational 
flattening,  with  less  District/Group  Commands.  Combining  OIS  with  the  introduction  of 
improved  boats  and  aircraft  will  enable  the  Coast  Guard  to  operate  with  fewer  resources  in  the 
field.  This  is  an  important  enabler  in  meeting  the  Commandant’s  third  strategic  goal:  “meet  the 
mandate  to  streamline  with  no  reduction  in  essential  services.” 

The  Coast  Guard  should  not  implement  pen-based  computers  for  boarding  officers  at  this  time. 
The  Group/Station  Testbed  results  indicate  that  boarding  officers  felt  a  decrease  in  situational 
awareness.  The  next  section  contains  a  recommendation  for  further  research  in  this  promising 
area. . 
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Embedding  decision  support  functionality  within  OIS  can  improve  the  quality  of  decision  making 
at  all  levels  of  the  chain  of  command.  It  can  also  eliminate  the  need  for  extensive  resident  training 
on  calculation  and  rule-based  tasks.  Training  can  focus  on  educating  the  person  about  the 
rationale  behind  performing  tasks,  but  does  not  need  to  cover  implementation  details.  This  is 
especially  valuable  for  tasks  which  are  performed  infrequently  but  are  procedure-intensive.  It  also 
allows  program  managers  to  update  policies  and  procedures  easily  by  updating  the  decision 
support  system. 

OIS  provides  a  tool  for  improved  measurement  of  our  operational  services,  and  therefore  better 
management  of  the  resources.  Capturing  employment  data  as  a  byproduct  of  operations  will 
increase  accuracy  and  decrease  workload. 

8.2  Recommendations 

Based  on  the  results  of  the  Group/Station  Operational  Information  System  Testbed,  the  Research 
and  Development  Center  recommends  the  following. 

That  the  Coast  Guard  continue  development  of  the  Operational  Information  System  for  Search 
and  Rescue  and  Law  Enforcement,  as  described  in  the  functional  decomposition  in  Appendix  E, 
and  deploy  it  Coast  Guard-wide.  This  includes  the  functions  currently  performed  by  the  Law 
Enforcement  Information  System  II;  the  Search  and  Rescue  Management  Information  System; 
and  the  Abstract  of  Operations  System. 

That  the  Coast  Guard  use  the  Operational  Information  System  as  a  framework  to  integrate  other 
major  systems  already  in  development.  These  include  the  Marine  Safety  Network  and  the  Vessel 
Traffic  System  2000.  In  addition  to  these  major  acquisitions,  the  Coast  Guard  has  a  substantial 
investment  in  the  Navy’s  Joint  Maritime  Command  Information  System  (JMCIS),  or  some  of  its 
variants.  Both  major  cutters  and  major  command  centers  ashore  are  currently  users  of  these 
systems.  This  item  will  require  that  OIS  exploit  multi-level  security  technology. 

That  the  Coast  Guard  implement  the  alternative  in  the  Short  Range  Communications  System 
proposals  which  includes  the  most  capable  data  transfer  capabilities,  including  secure  data 
transmission. 

That  the  Coast  Guard  implement  a  long  range  data  communications  system  as  part  of  an  overall 
communications  architecture  designed  to  extend  the  existing  shore-based  wide  area  network  to  its 
operating  resources. 

That  further  research  be  done  on  human  factors  issues  surrounding  use  of  portable  computers 
during  boardings.  The  potential  exists  to  improve  the  boarding  process,  but  the  results  of  the 
Group/Station  Testbed  were  negative  toward  use  of  portable  computers.  This  was  clearly  due  in 
large  part  to  technical  flaws  in  the  testbed  system,  but  there  remained  a  large  unwillingness  to 
commit  to  use  of  computers  during  boardings.  The  primary  concern  is  that  computers  would 
require  too  much  attention,  detracting  from  the  boarding  party’s  situational  awareness  and  safety. 
Unless  further  research  indicates  with  a  high  degree  of  probability  that  design  improvements  can 
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eliminate  the  concern  about  situational  awareness,  we  recommend  against  implementation  of 
portable  computers  during  boardings. 
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APPENDIX  A:  DETAILED  RESEARCH  RESULTS 

All  18  candidate  metrics  and  the  hypotheses  they  support  are  listed  below.  The  ones  selected  for 
measurement  are  italicized.  Metrics  1  and  2  are  similar  to  metrics  8-11;  the  difference  is  that  1&2 
apply  to  field  personnel  (boat  crews),  while  8-1 1  apply  to  command  center  personnel  (OODs, 
RMOWs,  watchstanders). 

A.  OIS  will  reduce  data  entry  and  report  preparation  time. 

1.  Time  to  enter  data  in  the  field 

2.  Time  to  transcribe  data  in  the  field 

3.  Time  to  prepare  reports 

4.  Time  spent  on  adhoc  (on-request)  reports 

5.  Amount  of  overtime 

B.  OIS  will  increase  accuracy  and  completeness  of  reports. 

6.  Number  of  errors  detected  in  manual  case  reviews 

7.  Number  of  required  and  optional fields  missing  from  reports 

C.  OIS  will  improve  command  and  control  by  reducing  response  time. 

8.  Time  to  record  data  (at  initial  distress  call) 

9.  Time  to  transcribe  data  into  OIS 

10.  Time  to  identify  resources 

11.  Time  to  dispatch 

D.  OIS  will  improve  navigational  accuracy  of  standard  boats. 

12.  Search  pattern  execution  accuracy 

E.  OIS  will  provide  better  on-scene  information  to  field  personnel. 

13.  Number  of  effective  LE  boardings 

14.  Number  of  LEIS  violations  overturned 

15.  Number  of  recreational  boating  safety  violations 

16.  Number  of  manuals  accessed  on  board 

17.  Number  of  queries  to  LEIS  II 

18.  Avoid  doing  the  wrong  boardings 

The  remainder  of  this  appendix  presents  the  raw  results  of  the  objective  and  subjective  measures 
recorded  during  the  OIS  Phase  One  testbed. 


Experiment  Raw  Data 


Experiment  1:  Time  Study 

The  raw  data  from  the  control  group  for  this  study  were  analyzed  and  found  not  to  be  reliable 
enough  for  valid  analysis.  Therefore,  the  results  were  not  tabulated  in  a  manner  suitable  for 
display.  There  is  a  detailed  discussion  of  the  factors  surrounding  this  problem  in  Chapter  5, 
Research  Results. 
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Experiment  2:  Report  Preparation  Time 

Table  8  lists  the  raw  data  regarding  SEER  report  preparation  time,  the  pre-OIS  LE  reporting 
system.  These  data  were  collected  at  five  Stations  in  Group  Moriches  during  the  spring  of  1994. 

Table  8:  Pre-OIS  LE  reporting  times. 


SEER  Msg 

SEER 

Number  of 

Time  / 

Date 

Number 

Time 

Boardings 

Boarding 

4/12/94 

3 

30 

1 

30.0 

4/21/94 

4 

15 

1 

15.0 

4/22/94 

5 

25 

2 

12.5 

4/24/94 

6 

21 

3 

7.0 

4/25/94 

7 

16 

1 

16.0 

4/19/94 

9 

30 

4 

7.5 

4/22/94 

10 

18 

2 

9.0 

4/25/94 

11 

18 

2 

9.0 

4/25/94 

12 

12 

1 

12.0 

5/13/94 

13 

12 

1 

12.0 

5/14/94 

14 

18 

1 

18.0 

5/14/94 

15 

24 

2 

12.0 

5/15/94 

16 

24 

3 

8.0 

5/17/94 

17 

45 

4 

11.3 

5/18/94 

18 

40 

2 

20.0 

5/19/94 

33 

15 

0 

0.0 

6/9/94 

17 

45 

4 

11.3 

6/14/94 

18 

40 

2 

20.0 

5/8/94 

10 

18 

2 

9.0 

5/12/94 

11 

18 

2 

9.0 

5/19/94 

12 

12 

1 

12.0 

5/21/94 

13 

12 

1 

12.0 

5/27/94 

14 

18 

1 

18.0 

6/4/94 

15 

24 

2 

12.0 

6/6/94 

16 

24 

3 

8.0 

4/24/94 

9 

30 

4 

7.5 

Sum: 

604 

318 

Count: 

26 

52 

Mean: 

23.2 

2.0 

12.2 

Std  Dev: 

10.0 

5.7 

A_0 
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Table  9  lists  the  raw  data  regarding  post-OIS  LE  reporting.  These  data  were  collected  in  Group 
Long  Island  Sound  during  the  summer  of  1994. 

Table  9:  Post-OIS  LE  reporting  time. 


Boarding 

Time  to 

Date 

Number 

Validate 

8/5/94 

145 

3 

8/5/94 

146 

4 

8/5/94 

147 

3 

8/6/94 

148 

3 

8/6/94 

149 

3 

8/6/94 

150 

3 

8/7/94 

151 

4 

8/7/94 

152 

4 

8/8/94 

153 

3 

7/21/94 

110 

10 

7/21/94 

111 

10 

7/21/94 

114 

10 

7/28/94 

123 

9 

7/29/94 

124 

14 

7/30/94 

126 

4 

7/30/94 

127 

4 

7/30/94 

128 

4 

7/30/94 

130 

3 

7/30/94 

131 

5 

7/30/94 

132 

4 

7/30/94 

133 

5 

7/30/94 

134 

5 

7/30/94 

135 

7 

7/31/94 

136 

5 

7/31/94 

137 

5 

7/31/94 

138 

5 

8/1/94 

139 

4 

8/1/94 

140 

2 

8/2/94 

141 

3 

8/3/94 

142 

5 

8/5/94 

144 

4 

Sum: 

157 

Count: 

31 

Mean: 

5.1 

Std  Dev: 

2.7 
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Table  10  lists  the  raw  data  regarding  SARMIS  report  preparation  time,  the  pre-OIS  SAR 
reporting  system.  These  data  were  collected  at  five  Stations  in  Group  Moriches  during  the  spring 

of  1994. 


Table  10: 


Pre-OIS  SARMIS  reporting  times, 


SARMIS 

D>U  Tlmt  SITREPTImt 

4/19/94 
4/19/94 
4/23/94 
4/23/94 
4/24/94 
4/24/94 
4/18/94 
4/19/94 
4/24/94 
4/24/94 
4/24/94 
4/24/94 
5/13/94 
5/13/94 
5/14/94 
5/14/94 
5/15/94 
4/18/94 
4/19/94 
4/21/94 
4/24/94 
4/24/94 
4/27/94 
5/1/94 
5/1/94 
5/15/94 
5/21/94 
5/28/94 
5/28/94 
5/28/94 
5/28/94 
5/28/94 
6/4/94 
6/15/94 
7/2/94 
7/2/94 
7/3/94 
7/4/94 
7/5/94 
7/6/94 
7/8/94 
3/6/94 
3/17/94 
3/19/94 
3/25/94 
3/26/94 
3/26/94 
3/26/94 
3/28/94 
3/30/94 
4/1/94 
4/4/94 
4/7/94 
4/16/94 
4/18/94 
4/18/94 
4/22/94 
4/22/94 
4/23/94 
4/24/94 
4/25/94 
4/26/94 
4/27/94 
4/28/94 
4/28/94 
4/30/94 
5/13/94 
5/13/94 
5/14/94 
5/15/94 
5/15/94 
5/16/94 


SARMIS 

Pit* _ Thn*  SrTREPTIm* 

5/16/94  10 

5/1 7/94  5 

5/1/94  10 

5/2/94  10 

5/4/94  15 

5/9/94  10 

5/20/94  10 

5/21/94  10 

5/21/94  10 

5/21/94  15 

5/21/94  IS 

5/22/94  10 

5/22/94  10 

5/22/94  10 

5^22/94  10 

5/24/94  15 

5/24/94  10 

5/24/94  10 

5/25/94  10 

5/25/94  10 

5/25/94  15 

5/25/94  10 

5/25/94  10 

5/25/94  10 

5/25W  10 

5/25/94  15 

5/26/94  10 

5/27/94  10 

5/28/94  10 

5/29/94  1  0 

5/29/94  15 

5/29/94  10 

5/29/94  10 

5/30/94  10 

5/30/94  10 

5nCV94  10 

5/30/94  15 

5/30/94  10 

5/30/94  10 

5/30/94  10 

5/30/94  10 

5/30/94  10 

5/31/94  10 

5/31/94  15 

5/31/94  10 

5/31/94  10 

5/31/94  10 

6/2/94  10 

6/3/94  10 

6/3/94  15 

6/4/94  12 

6/4/94  10 

6/4/94  15 

6/4/94  13 

6/4/94  12 

6/5/94  10 

6/6/94  12 

6/6/94  15 

6/6/94  15 

6/7/94  12 

6/7/94  13 

6/8/94  10 

6/9/94  15 

6/9/94  15 

6/9/94  13 

6/9/94  14 

6/10/94  12 

6/1 2/94  10 

6/14/94  15 

6/15/94  13 

6/15/94  13 

6/15/94  12 


SARMIS 

Pit* _ Tlw*  StTREPTIro* 

6/16/94  14 

6/18/94  15 

6/18/94  12 

6/18/94  13 

6/18/94  15 

6/18/94  10 

6/18/94  12 

6/18/94  13 

6/18/94  10 

6/18/94  13 

6/18/94  10 

6/19«4  12 

6/19/94  13 

6/19/94  15 

6/19/94  15 

6/19/94  13 

6/19W  13 

6/19/94  12 

6/19/94  10 

6/19/94  12 

6/19/94  13 

6/20/94  14 

6/20/94  14 

6/20/94  10 

6/22/94  14 

6/22/94  12 

6/25/94  15 

6/26/94  10 

6/26/94  12 

6/26/94  13 

6/26/94  14 

6/26/94  15 

6/27/94  13 

6/27/94  14 

6/27/94  13 

6/27/94  10 

6/28/94  12 

6/28/94  13 

6/28/94  15 

6/29/94  15 

6/29/94  15 

6/30/94  12 

6/30/94  13 

8/1/94  10 

8/4/94  12 

8/4/94  12 

e/4/94  15 

6«/94  15 

8/6/94  13 

8/6/94  10 

8/6/94  10 

8/6/94  12 

8/6/94  10 

8/6/94  12 

8/7/94  12 

8/7/94  15 

8/7/94  12 

8/7/94  10 

8/8/94  12 

8/8/94  12 

8/9/94  15 

8/9/94  13 

8/9/94  14 

8/9W  10 

e/13/94  12 

8/13/94  15 

8/14/94  13 

8/14/94  12 

8/14/94  11 

8/14/94  10 

8/14/94  15 

8/14/94  13 


SARMIS 

PM* _ Tiro*  SITWEPTIm* 

8/14/94  14 

8/15/94  12 

6/15/94  U 

8/16/94  12 

8/17/94  13 

8/20/94  12 

8/20/94  10 

8/20/94  12 

8/20/94  10 

6/20/94  11 

8/21/94  13 

6/21/94  14 

8/21/94  14 

8/23/94  10 

8/23/94  12 

8/23/94  11 

8/24/94  15 

8/24/94  13 

8/26/94  12 

8/27/94  13 

8/27/94  13 

6/27/94  11 

8/28/94  12 

8/28/94  10 

8/28/94  14 

8/28/94  10 

8/28/94  10 

8/28/94  11 

8/30/94  12 

8/30/94  12 

8/31/94  10 

8/31/94  12 

9/1/94  13 

9/2/94  12 

9/3/94  10 

9/3/94  11 

9/3/94  13 

9/3/94  10 

9/3/94  15 

9/4/94  10 

9/4/94  12 

9/4/94  10 

9/5/94  14 

9/5/94  10 

9/7/94  12 

9/9/94  10 

9/9/94  12 

9/10/94  13 

9/10/94  10 

9/10/94  10 

9/10/94  10 

9/11/94  15 

9/11/94  12 

9/11/94  10 

9/11/94  14 

9/11/94  12 

9/12/94  10 

9/13/94  10 

9/16/94  11 

9/16/94  11 

9/17/94  15 

9/17/94  n 

9/17/94  14 

9/17/94  11 

9/20/94  12 

9/21/94  15 

9/24/94  1  0 


9/25/94  12 

Sum:  3290 

CQunti  282  11 

Mtan:  11.7  36.0 

Std  Pay: _ 2^4 _ 118 


February  1995 


A-4 


USCG  Operational  info  System 


Group/Station  OIS  Testbed  Evaluation  Report 


Table  1 1  lists  the  raw  data  regarding  post-OIS  LE  reporting.  These  data  were  collected  in  Group 
Long  Island  Sound  during  the  summer  of  1994. 


Table  11:  Post-OIS  SAR  info  validation  times. 


Case  Num 

Time  to 
Validate 

304 

5.3 

347 

5.3 

346 

4.9 

345 

4.9 

344 

6.8 

343 

6.3 

342 

4.9 

341 

8.6 

340 

6.1 

339 

6.5 

338 

6.0 

337 

2.8 

335 

4.5 

334 

4.5 

333 

5.7 

332 

4.7 

331 

3.9 

330 

4.7 

329 

3.7 

328 

7.8 

327 

7.7 

326 

6.5 

325 

7.2 

324 

6.0 

323 

8.0 

332 

3.5 

321 

2.3 

320 

4.4 

319 

4.9 

318 

2.9 

317 

2.4 

316 

2.4 

315 

2.8 

314 

4.2 

313 

3.1 

310 

4.7 

309 

2.5 

308 

2.7 

307 

3.6 

306 

3.3 

302 

4.5 

301 

4.3 

298 

4.3 

297 

2.6 

296 

2.6 

295 

2.0 

294 

1.7 

293 

3.9 

292 

2.2 

Sum: 

221 

Count: 

49 

Mean: 

4.5 

Std  Dev: 

1.8 
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Experiment  3:  Completeness  of  Information 

Table  12  lists  the  data  elements  which  were  missing  in  each  of  the  case  folders  analyzed,  identified 
as  cases  1-10.  These  ten  cases  were  part  of  the  random  sample  of  20  cases  used  as  part  of  this 

test. 


Table  12:  Completeness  of  case  folders. 


Case 

Number 

List  of  data  elements  missing 

Case  1 

Time  from  Occurrence,  Initial  Severity,  Date  Case  Closed 

Case  2 

Vessel  Name,  Vessel  Registration  Number,  Vessel  Length,  Vessel  Usage,  Number  of 
people  on  Board 

Case  3 

Date/Time  Sortie  Ended,  Date/Time  Case  Closed 

Case  4 

Latitude,  Longitude,  Time  from  Occurrence,  Vessel  Owner  Name,  Vessel  Owner 
Address,  Vessel  Propulsion,  Initial  Severity,  Reported  Location  Date/Time,  Number 
of  peoole  on  board.  Type  of  Assistance  Required 

Case  5 

Vessel  Reeistration  Number,  Vessel  Owner  Name,  Vessel  Owner  Address 

Case  6 

Total  Time  on  Sortie,  Total  Time  on  Scene,  Reporting  Source,  Method  of 
Notification,  Reported  Latitude,  Reported  Longitude 

Case  7 

Reoorted  Latitude,  Reported  Longitude 

Case  8 

Reported  Latitude,  Reported  Longitude,  Date/Time  Incident  Occurred,  Assisting 
Resource  Type,  Distance  to  Scene  or  Search,  Total  Time  on  Sortie,  Total  Time  on 
Scene,  Method  of  Notification,  Reporting  Source,  Vessel  Length,  Vessel  Usage, 
Vessel  ProDulsion,  Number  of  people  on  board.  Initial  Severity 

Case  9 

Reported  Latitude,  Reported  Longitude,  Total  Time  on  Sortie,  Total  Time  on  Scene, 
Reporting  Source,  Vessel  Length,  Vessel  Usage,  Vessel  Propulsion,  Initial  Severity, 
Vessel  Owner  Name,  Vessel  Owner  Address 

Case  10 

Reported  Latitude,  Reported  Longitude,  Total  Time  on  Sortie,  Total  Time  on  Scene, 
Reporting  Source,  Vessel  Length,  Vessel  Usage,  Vessel  Propulsion,  Initial  Severity, 
Vessel  Owner  Name.  Vessel  Owner  Address,  Number  of  people  on  board 

Survey  Responses 

In  the  pages  that  follow,  survey  responses  are  tallied  and  percentages  of  respondents  calculated 
for  each  answer.  The  tallies  are  presented  in  a  framed  section  immediately  following  the  question, 
which  is  in  bold  type.  Immediately  following  each  tally  is  a  bulleted  list  of  all  user  comments 
made  in  response  to  that  question. 

The  blank  questionnaires  are  presented  immediately  following  the  tallies. 
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OIS  Questionnaire  1  -  Command  and  Control 
Respondents;  Command  center  personnel,  N=23 


When  you  answer  a  distress  call,  how  do  you  record  the  information? 


1 

5% 

1  type  it  directly  into  the  computer 

7 

33% 

some  info  1  type  into  the  computer  &  some  1  write  on  paper  - 

which  info/why? 

12 

57% 

1  write  it  on  paper  -  why  not  use  the  computer? 

1 

5% 

n/a--l  don't  perform  this  function 

•  Some  in  computer,  some  on  paper:  I  don 't  have  time  to  type  all  the  info  and  talk  on  the 


radio.  So  1  usually  just  begin  the  case  in  OIS  and  fill  out  the  blanks  when  1  get  the  chance. 

•  Some  in  computer,  some  on  paper:  Initial  info  for  case  then  into  computer. 

•  Some  in  computer,  some  on  paper:  Faster  to  put  initial  info  on  paper. 

•  Some  in  computer,  some  on  paper:  Still  easier  for  me  to  note  then  enter  using  paper 
checklists  when  necessary. 

•  On  paper:  In  a  distress  case,  it  is  easier  for  me  to  use  pen/ink  for  quick  important  facts,  and 
sort  it  out  after. 

•  On  paper:  I'm  more  mobile  with  paper.  I  can  write  on  paper  then  enter  later  -  duplicate  my 
effort? 

•  On  paper:  Because  during  the  initial  SAR  call  I  want  to  be  in  the  commcen,  to  make  sure  the 
proper  info  is  gathered. 

•  On  paper:  I  take  the  info  and  put  it  on  the  appropriate  checklist  required  by  the  group.  I 
can 't  type  and  hold  the  mike  at  the  same  time  either. 

•  On  paper:  Sometimes  you  have  to  clear  out  one  case  to  enter  another.  Takes  too  long. 

•  On  paper:  Easier  to  jot  down  quickly  than  to  type. 

•  On  paper:  Takes  too  long. 

•  On  paper:  Often  the  information  is  passed  so  quickly  that  I  feel  more  comfortable  writing  it 
down  first  then  transferring. 

•  On  paper:  There 's  no  way  until  the  situation  is  under  control. 

•  On  paper:  Quicker  on  paper  in  order  to  respond  faster. 

•  On  paper:  I  write  down  the  info  then  type  it  into  the  computer.  The  info  had  to  be  recorded 
quickly. 

•  On  paper:  I  write  it  on  paper  because  I  can  write  faster  than  I  can  type  into  a  computer. 

•  On  paper:  I  don 't  perform  this  function,  but  I  see  the  watchstanders  normally  jot  down  the 
initial  info  and  later  record  in  OIS. 


How  easy  or  difficult  is  it  to  type/transcribe  case  data  into  the  OIS  system? 


3 

14% 

very  easy 

17 

77% 

fairly  easy 

1 

5% 

fairly  difficult  --  describe  problems 

1 

5% 

unacceptably  difficult  -  describe  problems 

0 

0% 

n/a--l  haven't  done  this 

•  Fairly  difficult:  It  wouldn 't  be  so  bad  if  it  one  case  at  a  time,  we  are  usually  running  2 
or  3  at  a  time. 


•  Fairly  difficult:  Takes  too  long.  Too  much  data  is  not  applicable.  Problems  with  computer 
slows  process. 
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•  Unacceptably  difficult:  OIS  isn ’t  intuitive.  Icons  and  data  entry  into  fields  that  may  not  apply 
to  the  task  at  hand  detract  from  the  task  at  hand  -I’m  SAR  oriented. 


How  easy  or  difficult  is  it  to  retrieve  (look  up)  case  data  in  OIS? 


1  IWVV 

7 

32% 

very  easy 

13 

59% 

fairly  easy 

2 

9% 

fairly  difficult  --  describe  problems 

0 

0% 

unacceptably  difficult  --  describe  problems 

0 

0% 

n/a  -- 1  haven't  done  this 

*  Fairly  difficult:  When  it ’s  not  crashing  it ’s  easy. 

•  Fairly  difficult:  Once  archived,  it ’s  a  bear  to  retrieve  a  lot  of  cases.  I  look  at  it  from  SARMS 
coordinator  aspect  -  needs  work  or  a  user  name  with  some  broader  scope  queries. 


Do  the  Graphical  Information  System  (GIS-the  electronic  map)  and  OIS  affect  how 
quickly  you  can  identify  and  dispatch  SAR  boats  on  a  case?  Compared  to  the  way  you 
operated  previously,  would  you  say  that  the  time  to  identify  and  dispatch  SAR  boats  is: 


0 

0% 

much  faster  with  GIS/OIS 

1 

5% 

a  little  faster  with  GIS/OIS 

14 

64% 

about  the  same  with  GIS/OIS  as  before 

2 

9% 

a  little  slower  with  GIS/OIS  --  describe  problems 

2 

9% 

much  slower  with  GIS/OIS  -  describe  problems 

3 

14% 

n/a--l  haven’t  done  this 

•  About  the  same:  The  position  of  the  boat  is  15  minutes  from  update  to  update.  I  still  check 


the  location  of  the  UTB  before  I  assume  this  is  the  current  position. 

•  Much  slower:  Charted  boat  positions  rarely  accurate.  Much  easier  to  simply  hail  boat  on 
VHF. 

•  A  little  slower:  The  screen  did  not  function  properly  most  of  the  time. 


In  your  opinion,  does  the  OIS  system  affect  the  ease  with  which  case  data  are  updated 
and  shared  between  the  group,  stations,  and  SAR  boats?  Compared  to  the  way  you 
operated  previously,  would  you  say  that:  _ 


2 

9% 

OIS  makes  it  much  more  difficult  to  share  and  update  case  data  -  why? 

2 

9% 

OIS  makes  it  a  little  more  difficult  to  share  and  update  case  data  -  why? 

5 

22% 

OIS  doesn't  change  our  ability  to  share  and  update  case  data 

11 

48% 

OIS  makes  it  a  little  easier  to  share  and  update  case  data 

3 

13% 

OIS  makes  it  much  easier  to  share  and  update  case  data 

•  Much  more  difficult:  The  system  is  always  crashing. 

•  A  little  easier:  Provided  it’s  entered.  Not  easy  to  immediately  find  the  new  data.  Have  to 


search  many  fields  to  ferret  out  new  data. 

•  A  little  more  difficult:  Some  stations  don ’t  add  info  that  should  be  added  in  a  timely  fashion. 

•  A  little  more  difficult:  Have  experienced  problems  with  other  units  using  our  OFF  AC, 
making  case  ID  difficult. 

•  A  little  easier:  If  everything  is  up  and  running  properly  it  is  easier  to  share  info. 

How  has  OIS  affected  the  number  of  cases  you  can  handle  simultaneously?  Compared  to 

the  way  you  operated  previously,  would  you  say  that  with  OIS,  you  handle. _ 

0  0%  more  cases  simultaneously  than  before?  _ 
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14  64%  about  the  same  number  of  cases  as  before? 

8  36%  fewer  cases  simultaneously  than  before?  -  why? _ 

•  Fewer:  It  was  rare  the  system  was  up.  Either  shoreside  or  u/w  sorties. 

•  Fewer:  Again,  it  is  easier  to  write  on  a  checklist  than  scroll  through  menus  and  screens. 

0  Fewer:  More  work  than  previously. 

0  Fewer:  Too  much  computer  work. 

0  Fewer:  It  takes  me  longer  to  change  windows  and  move  to  previous  case  than  it  does  to  write 
it  down. 

0  Fewer:  If  I 'm  working  multiple  cases  I  wait  until  they  are  all  done  before  I  type  into  OIS. 


Do  you  ever  have  more  cases  than  you  can  handle  all  at  once?  If  so,  what  do  you  do? 
Has  OIS  affected  this  in  any  way? _ _ 


12 

57% 

no 

9 

43% 

_yei _ 

*  Yes:  I  get  help  from  the  CDO. 

0  Yes:  I  get  another  watchstander  to  answer  the  radio,  write,  answer  phones,  talk  to  group 
OOD.  It  gets  hectic  with  or  without  OIS. 

0  Yes:  Call  in  more  watchstanders/OOD. 

0  Yes:  Have  someone  help/forget  about  OIS. 

0  Yes:  I  usually  get  another  person  in  the  commcenter  to  answer  the  phones  and  to  help  out 
with  other  functions.  OIS  hasn ’t  affected  anything  but  when  it  is  very  busy  there  is  no  way  I 
can  use  it  and  still  do  everything  else. 

0  Yes:  I  ask  Group  for  radio  comms  assistance. 

0  No:  as  long  as  I  don ’t  use  OIS  until  the  case  is  done. 

Is  there  anything  else  you'd  like  us  to  know  about  your  experiences  with  the  OIS  system? 

0  The  shore-based  system  alone  would  be  great. 

0  Validating  cases  becomes  a  problem  when  you  have  to  enter  a  zero  just  to  fill  in  a  box. 

0  Input  was  very  easy.  Output  was  more  difficult  than  it  was  prior  to  system  (OIS). 

0  OIS  shoreside  should  be  installed  everywhere  SARMTS  is  used.  It 's  a  much  easier  .system. 

0  OIS  would  work  great  at  a  station  that  handles  a  few  cases  (100-200  a  year)  where  the 
commcen  is  set  up  so  the  watchstander  has  a  foot  pedal  for  the  mike  to  keep  their  handsfree. 
I  hard/difficult  to  talk  on  the  UHF  with  1  hand  and  try  to  type  OIS  with  1  finger. 

0  When  a  case  happens  we  retrieve  a  checkoff  sheet  for  whatever  the  situation  is  and  fill  it  out. 
The  OIS  would  be  more  helpjul  if  it  were  set  up  the  same  way.  That  should  be  the  first 
screen  we  open  -  then  get  all  other  info. 

0  System  frequently  malfunctions,  keyboard  and  trackball  unreliable,  transmission  frequently 
down  or  not  timely.  Better,  more  durable  hardware  is  a  must.  Pen-based  is  basically 
unusable  and  lack  of  reliability  caused  use  to  be  infrequent.  Shoreside  system  may  have  a 
future  with  some  hardware  upgrades.  U/W  system  is  not  practical,  ECDIS  has  future,  but 
paper  is  here  to  stay  as  best  possible  system. 

0  Great  concept!  Make  simpler,  something  more  workable  without  tasking  an  already 
overtasked  crew.  PS:  Possibly  make  Group  run  system. 

0  It ’s  easier  than  SARMIS. 

0  The  system  is  great.  With  some  more  work  it  could  be  very  beneficial. 

0  I  think  we  need  like  a  basic  typing  class. 
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OIS  Questionnaire  2  -  Operational  Reporting 
Respondents:  Boat  crews  and  station/group  personnel,  N=15 

How  often  do  you  record  SAR  or  LE  case  information  and-or  prepare  SAR  or  LE  reports? 

14  82%  frequently 

1  6%  sometimes 

2  12%  almost  never  --  STOP  HERE _ _ _ 


you  record  case  or  boarding  Information  on  paper  or  forms,  about  how 
many  minutes  does  it  take... _ _ _ _ _ _ 


many  iiiii 

N 

mu 

sigma 

for  the  average  SAR  case? 

14 

11.2 

6.6  min 

(a) 

11 

16.1 

9.4  min 

(b) 

for  the  average  LE  case? 
n/a--l  don't  perform  this  function 

(Pre-OlS)  About  how  long  does  It  take  to  prepare  the  necessary  SAR  and  LE  reports  at 


UlfS  diaiiu 

N 

n  1  z 

mu 

sigma 

for  the  average  SAR  case? 

12 

16.4 

15.3  min 

(a) 

10 

16.9 

6.9  min 

(b) 

for  the  average  LE  case? 
n/a--l  don't  perform  this  function 

(Pre-OIS)  How  easy  or  difficult  is  it  to  prepare  these  reports? 
2  15%  very  easy 

9  69%  fairly  easy 

1  8%  fairly  difficult  -  describe  problems 

0  0%  unacceptably  difficult  --  describe  problems 

1  8%  n/a-l  don't  perform  this  function _ 


The  remaining  questions  should  be  asked  during  the  POST-OIS  data  collection.  The  first 
four  questions  are  for  the  boat  crews;  the  rest  of  the  questions  are  for  all 
boat/station/group  personnel  involved  in  SAR/LE  reporting. 


0 

W  will// 

0% 

into  the  pen-based  computer  only 

5 

33% 

some  info  into  the  computer  &  some  on  paper  -  which  info/why? 

6 

40% 

only  onto  paper  -  why  don't  you  use  the  computer? 

0 

0% 

n/a-l  don't  perform  this  function 

4 

27% 

no  response 

^  _  /  f  .  .  .  #TT  t  *  _  _7 

- ^  - r  X  - 

Only  onto  paper:  Too  difficult. 

Only  onto  paper:  Have  to  prepare  for  case  and  limited  in  the  amount  of  time. 

Some  into  computer  and  some  onto  paper:  You  can  use  penbase  in  rough  seas  and  takes 
twice  as  long  to  do  job. 

Some  into  computer  and  some  onto  paper:  Not  always  functioning 
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(boat  crew  only)  When  you  record  case  or  boarding  information  on  paper  or  forms, 
about  how  many  minutes  does  it  take...  _ 


N 

mu 

sigma 

10 

9.3 

6.1  min 

(a)  for  the  average  SAR  case? 

8 

12.8 

6.0  min 

(b)  for  the  average  LE  case? 

1  don't  record  data  onto  paper  or  forms;  1  usually  use  the 

pen-based  computer. 

n/a-l  don't  perform  this  function 

•  Fairly  difficult:  Chasing  icons  and  looking  for  required  fields. 


(boat  crew  only)  When  you  record  boarding  data  directly  into  the  pen-based  computer 
(that  is.  you  don’t  write  it  on  paper  first),  about  how  long  does  it  take... _ 


N 

mu 

sigma 

2 

15.0 

7.1  min 

(a)  for  the  average  SAR  case? 

3 

25.0 

13.2  min 

(b)  for  the  average  LE  case? 

1 

1  don't  record  data  into  the  computer;  1  usually  use  paper. 

n/a--!  don't  perform  this  function 

•  1  don 't:  Paper  first  then  OIS,  near  impossible  to  real-time. 


(boat  crew  only)  How  easy  or  difficult  is  it  to  transmit  SAR  or  boarding  data  from  the  pen- 
based  computer  to  the  OIS  system  at  the  station? _ 


0 

0% 

very  easy 

2 

18% 

fairly  easy 

4 

36% 

fairly  difficult  ~  describe  problems 

1 

9% 

unacceptably  difficult  -  describe  problems 

4 

36% 

n/a~l  haven't  done  this 

•  Fairly  difficult:  Not  always  functioning.  Easy  when  everything  is  working  properly. 

•  Unacceptably  difficult:  Never  reliable,  time  lapse  too  great. 


All  boat/station/group  personnel  involved  in  SAR/LE  reporting. 


When  SAR  or  boarding  information  has  been  recorded  onto  paper  first,  about  how  long 
does  it  take  to  transcribe  that  information  into  the  computer  (either  on  board  or  at  the 
station)... _ _ _ 


N 

mu 

sigma 

11 

14.4 

6.4  min 

(a)  for  the  average  SAR  case? 

9 

15.3 

7.2  min 

(b)  for  the  average  LE  case? 

How  easy  or  difficult  is  it  to  transcribe  SAR  or  boarding  data  from  paper  forms  into  the 
OIS  system  (either  on  board  or  at  the  station)? _ 


3 

20% 

very  easy 

8 

53% 

fairly  easy 

2 

14% 

fairly  difficult  -  describe  problems 

0 

0% 

unacceptably  difficult  -  describe  problems 

2 

14% 

n/a-l  haven't  done  this 

How  easy  or  difficult  is  it  to  prepare  reports  using  the  OIS  system? 

1 _ 7%  very  easy  _ 
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10 

67% 

fairly  easy 

2 

13% 

fairly  difficult  ~  describe  problems 

0 

0% 

unacceptably  difficult  -  describe  problems 

2 

13% 

n/a-'l  haven’t  done  this 

•  Fairly  easy:  when  everything  is  working  properly. 

•  Fairly  difficult:  Data  transfer  problems  from  OIS  to  CGSWS. 

•  Fairly  difficult:  It  can  be  very  time  consuming  sometimes  waiting  for  screens  to  come  up. 


About  how  long  does  it  take  to  use  the  OIS  system  to  prepare  the  necessary  reports... 


Il\i 

N 

mu 

sigma 

^  ^  . 

(a)  for  the  average  SAR  case? 

12 

10.1 

6.3  min 

8 

12.1 

8.0  min 

(b)  for  the  average  LE  case? 

1  don't  record  data  into  the  computer;  1  usually  use  paper, 
n/a-l  don't  perform  this  function 

How  would  you  compare  the  time  it  takes  to  enter  case  or  boarding  data  and  prepare 

_ /MC  /«r\mnsiraH  fn  fho  wav  VOU  LlSed  tO  dO  thlS? 


1  CpV/l  M 

4 

011  1^  aw 

27% 

OIS  takes  much  more  time  ~  why? 

4 

27% 

OIS  takes  a  little  more  time  ~  why? 

4 

27% 

OIS  takes  about  the  same  amount  of  time 

2 

13% 

OIS  takes  a  little  less  time 

0 

0% 

OIS  takes  much  less  time 

1 

7% 

no  basis  to  compare 

•  Ulc>  lutces  mucri  rnum  .ryv,  . 

•  OIS  takes  much  more  time:  You  have  to  look  around  for  proper  icon  to  click  on,  wait  for 
screen,  perform  scroll  functions,  and  if  you  're  lucky  hope  it  doesn 't  crash  which  is  time 
consuming. 

•  OIS  takes  much  more  time:  File  transfer  time  (OIS  to  CGSW)  and  editing  datafiles. 

•  OIS  takes  a  little  more  time:  Have  to  bring  up  different  screens. 

•  OIS  takes  a  little  more  time:  Transmit  time,  screen  inputs  timely. 

•  OIS  takes  a  little  more  time:  You  have  to  add  unnecessary  data  into  OIS. 

In  your  opinion,  has  the  OIS  system  affected  the  accuracy  of  the  Information  In  the 


1  s 

3 

20% 

accuracy  has  improved  with  OIS  ~  why? 

10 

67% 

accuracy  is  about  the  same 

2 

13% 

accuracy  is  worse  with  OIS  -  why? 

forgotten. 

Accuracy  is  worse  with  OIS:  Sometimes  when  you  enter  information  in  OIS  you  're  not  sure  if 
it  will  validate. 

Accuracy  is  worse  with  OIS:  Its  screens  for  some  situations  are  too  vague  or  non-exi.'stent. 
Accuracy  is  worse  with  OIS:  Some  data  must  be  fabricated  or  omitted  in  order  to 
successfully  validate  case  folders. 


OIS  Questionnaire  3  -  On-Scene  Operations 
Respondents:  Coxswains  N=10 
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Electronic  Chart:  The  first  few  questions  are  about  the  electronic  chart  (ECDIS) 
and  how  it  has  affected  your  navigation  tasks. 


How  has  the  electronic  chart  (ECDIS)  affected  your  time  to  arrive  on  station?  Compared 
to  navigating  without  ECDIS.  would  you  say  that  with  ECDIS: _ 


4 

40% 

it  takes  much  less  time  to  arrive  on  station  than  before  --  why? 

1 

10% 

it  takes  a  little  less  time  to  arrive  on  station  --  why? 

5 

50% 

it  takes  about  the  same  amount  of  time  as  before 

0 

0% 

it  takes  a  little  more  time  to  arrive  on  station  --  why? 

0 

0% 

it  takes  much  more  time  to  arrive  on  station  --  why? 

•  Little  less:  If  you  are  navigating  to  an  exact  location/position  such  as  a  water  depth  you  can 


visually  watch  the  ECDIS  instead  of  a  radar  fix  or  LORAN/GPS  fix. 

•  Much  less:  Easy  access  to  look  at  and  a  quick  check  on  position. 

•  Much  less:  Takes  away  from  majority  of  chart  work. 

•  Much  less:  With  the  ECDIS  and  GPS  you  get  a  quicker  look  at  where  you  are  especially 
around  the  Thimbles  area  or  any  area  in  AOR. 


How  has  the  electronic  chart  (ECDIS)  affected  the  accuracy  of  executing  search 
patterns?  Compared  to  navigating  without  ECDIS,  would  you  say  that  with  ECDIS  search 
patterns  are  executed: _ _ _ _ _ 


p - : — 

0 

0% 

much  less  accurately  than  before  -  why? 

0 

0% 

a  little  less  accurately  --  why? 

5 

50% 

at  about  the  same  accuracy  as  before 

4 

40% 

a  little  more  accurately  --  why? 

1 

10% 

much  more  accurately  than  before  ~  why? 

•  Little  more:  The  ECDIS  can  be  used  as  a  quick  reference  in  between  fixes  to  determine  if  you 
are  being  set.  Also  it  is  one  more  navigational  aid  to  back  up  your  navigation  which 
improves  accuracy  and  speed  in  navigation. 


•  Little  more:  Being  used  with  GPS,  it ’s  bound  to  be  more  accurate. 

•  Much  more:  I  could  use  the  GPS  and  ECDIS  to  conduct  a  P/S  search  by  watching  the 
minutes  on  the  lat/long  to  make  my  course  changes  and  ultimately  conduct  a  more  thorough 
search. 

•  Much  more:  With  the  electronic  chart  you  can  see  your  tracklines  which  makes  your  search 
pattern  more  accurate. 

•  Much  more:  Much  easier  to  check  your  course  and  keep  your  course. 


How  has  the  electronic  chart  (ECDIS)  affected  your  navigational  workload  (that  is,  the 
amount  of  time  and  effort  you  must  devote  to  the  navigation  task)?  Compared  to 
navigating  without  ECDIS.  would  you  say  that  ECDIS: _ 


4 

40% 

greatly  decreases  your  navigation  workload  --  why? 

2 

20% 

slightly  decreases  your  navigation  workload  -  why? 

4 

40% 

neither  decreases  nor  increases  your  workload 

0 

0% 

slightly  increases  your  navigation  workload  --  why? 

0 

0% 

greatly  increases  your  navigation  workload  --  why? 
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•  Greatly  decreases:  This  is  a  sign  of  the  times.  Usually  aids  such  as  ECDIS  are  more 
accurate.  This  system  will  not  take  away  from  manually  taking  a  fix,  but  it  correlates  the 
manual  way  of  doing  things  with  the  effortless  way  of  ECDIS. 

•  Greatly  decreases:  GPS  is  very  accurate  so  by  just  looking  at  the  chart  you  have  displayed 
and  comparing  to  your  chart  it  takes  less  time  to  plot  your  position. 

•  Greatly  decreases:  You  can  draw  your  course  on  your  chart  and  keep  a  good  position  where 
you  are  with  ECDIS. 

•  Greatly  decreases:  ECDIS  is  extremely  useful,  it  simply  makes  things  easier. 

•  Slightly  decreases  :  As  a  reference  your  position  is  fixed  on  the  screen. 

•  Slightly  decreases  :  It  gives  you  more  assurance  of  your  current  position. 

•  Neither:  It  is  a  valuable  backup  but  not  a  substitute. 

What  do  you  like  best  about  ECDIS? 

•  It  is  a  valuable  quick  reference  in  between  fixes  and  back  up  for  positions. 

•  Easier  navigating. 

0  Quick  check. 

0  Makes  overall  job  easier  and  allows  you  to  shift  more  attention  to  the  case. 

0  It  is  a  highly  visible  aid.  It  is  easy  to  get  a  quick  reassurance  of  position. 

0  Visible  aid.  Double  checks  your  navigation. 

0  When  in  the  fog  it  gave  me  a  more  secure  feeling  of  knowing  exactly  where  I  was  at  all  times. 
0  I  like  the  fact  that  it  cuts  down  on  my  nav  time  and  also  gives  a  quick  easy  check  on  my 
position  when  running  on  a  SAR  call 
0  Accuracy. 

0  Ready  reference. 

What  do  you  like  least  about  ECDIS? 

•  There  is  nothing  not  to  like  about  it 

0  The  mouse  and  on-screen  arrow  are  too  sensitive'  and  very  difficult  to  use  in  any  sea 
conditions. 

0  Having  to  scroll  up  and  down  for  chart  you  need. 

0  Nighttime  use  and  it ’s  always  soins  off  and  not  receiving  info. 

0  Mouse/cursor. 

0  Mouse  was  unusable  in  rough  seas.  The  cursor  didn 't  contrast  with  the  chart 
0  The  mouse  hardly  works. 

0  Nothing. 

0  (1)  It  would  crash  when  I  hit  large  waves.  (2)  Can’t  see  the  cursor.  (3)  Get  a  headache 

trying  to  set  up  the  system  when  u/w  bouncing  around. 

Data  Transmission  with  OIS 

The  next  set  of  questions  deals  with  the  effects  of  using  OIS  to  send 
and  receive  case  information  compared  to  using  the  voice  radio. 

How  do  you  transmit  and  receive  case  information  to  and  from  the  station  or  group? 

0  0%  Almost  all  information  is  transmitted  and  received  via  OIS. 

1  10%  Some  info  is  via  OIS,  and  some  info  is  via  radio. 

2%  via  OIS  98%  via  radio _ 
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9  90%  Almost  all  info  is  via  radio  -  why  don't  you  use  OIS? _ 

•  Almost  all  via  radio:  It  is  quicker  and  easier  via  radio. 

•  Almost  all  via  radio:  You  must  be  alert  and  watching  the  situation.  To  enter  info  in  OIS 
means  you  cannot  do  this. 

•  Almost  all  via  radio:  Inconsistent. 

•  Almost  all  via  radio:  Unreliable  comms. 

•  Almost  all  via  radio:  OIS  clutters  up  nav  table  and  involves  too  much  concentration  into  the 
pen-based. 


•  Almost  all  via  radio:  It  takes  a  short  time  in  our  area  to  get  on  scene. 

•  Almost  all  via  radio:  You  have  to  have  a  dedicated  OIS  operator  to  man  the  system.  It  takes 
less  time  to  pass  info  via  radio  than  it  does  to  wait  for  info  to  be  received  via  OIS. 

•  Almost  all  via  radio:  Takes  too  much  time  and  also  takes  one  of  my  personnel  away  from  his 
normal  duties.  You  need  04  personnel  on  the  UTB  to  use  OIS  and  run  a  case. 

•  Almost  all  via  radio:  Too  slow. 


How  does  OIS  affect  the  time  it  takes  you  to  transmit  and  receive  case  information  (to 
and  from  the  station  or  group)?  Compared  with  using  the  radio,  would  you  say  that 

information  transmission  time  with  OIS  is:  _ 

8  80%  much  slower  than  using  the  radio  -  why? 

0  0%  a  little  slower  than  using  the  radio  -  why? 

2  20%  about  the  same  as  using  the  radio 

0  0%  a  little  faster  than  using  the  radio 

_ 0  0%  much  faster  than  using  the  radio  _ 

•  Much  slower:  When  transmitted  by  radio  it  can  come  almost  immediately  after  it  is  received 
whereas  by  OIS  it  needs  to  be  entered,  sent,  received  which  could  take  valuable  minutes. 

•  Much  slower:  Needed  information  is  transmitted  faster  via  radio. 

•  Much  slower:  Too  hard  to  use  on  a  moving  platform.  Takes  coxswain 's  eyes  off  situation. 

•  Much  slower:  I  can  talk  faster  than  I  can  type!! 

•  Much  slower:  Radio  is  risht  now. 

•  Much  slower  :  Until  the  system  is  perfected,  some  info  never  makes  the  screen. 

•  Much  slower:  It 's  easier  to  pick  up  a  radio  than  get  into  a  computer. 


How  does  OIS  affect  the  currency  of  the  information  you  receive  (that  is,  do  you  feel  OIS 
enables  you  to  keep  more  up-to-date  on  case  progress)?  Compared  to  using  the  radio, 
would  you  say  that  information  currency  with  OIS  is: _ 


4 

40% 

much  worse  (less  up-to-date)  than  with  the  radio  -  why? 

1 

10% 

a  little  worse  than  with  the  radio  ~  why? 

4 

40% 

about  the  same  as  with  the  radio 

1 

10% 

a  little  better  (more  up-to-date)  than  with  the  radio 

0 

0% 

much  better  than  with  the  radio 

*  A  little  worse:  Most  information  on  OIS  is  much  easier  passed  over  the  radio.  By  the  time  I 


get  OIS  on  line  the  case  is  half  over. 

•  Much  worse:  Same  as  above.  Radio  is  quicker. 

•  Much  worse:  Timely.  We  have  secured  frequencies. 

•  Much  worse:  I  am  also  listening  to  the  comms  the  station  has  with  the  v.d  we  are  enroute  to. 
Why  do  twice  as  much  work? 

•  Much  worse:  Radio  is  risht  now. 
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How  does  OIS  affect  the  accuracy  of  the  case  data  you  receive  from  the 
station/group/other  units?  Compared  with  using  the  radio,  would  you  say  that 
information  accuracy  with  OIS  is: _ _ _ _ _ 


II  II 

2 

18% 

much  more  accurate  than  with  the  radio 

1 

9% 

a  little  more  accurate  than  with  the  radio 

4 

36% 

about  the  same  accuracy  as  with  the  radio 

1 

9% 

a  little  less  accurate  than  with  the  radio  -  why? 

3 

27% 

much  less  accurate  than  with  the  radio  -  why? 

*  Much  more  accurate:  If  it  makes  the  screen  there ’s  no  guessing  about  what  the  radioman 


said;  it ’s  right  there  on  the  screen. 

•  Much  less  accurate:  Most  OIS  info  is  good  for  station  OOD.  Doesn  V  help  with  the  case 
compared  to  the  radio. 

•  Much  less  accurate:  Again,  radio  is  right  now. 


How  does  using  OIS  for  transmitting/receiving  information  affect  your  workload  (that  is, 
the  time  and  effort  you  devote  to  information  transfer)?  Compared  to  using  the  radio, 
would  you  say  that  with  OIS: _ _ _ _ 


4 

40% 

your  workload  is  much  greater  than  with  the  radio  -  why? 

3 

30% 

your  workload  is  a  little  greater  than  with  the  radio  -  why? 

2 

20% 

your  workload  is  about  the  same  as  with  the  radio 

1 

10% 

your  workload  is  a  little  less  than  with  the  radio 

0 

0% 

vour  workload  is  much  less  than  with  the  radio 

•  Much  greater:  We  don ’t  have  the  man  hours  to  train  people  on  the  OIS  to  where  it  became 
second  nature  as  in  with  talking  on  the  radio. 


•  Much  greater:  During  ops  there  has  to  be  a  dedicated  person  inputting  data  into  OIS.  With 
the  radio  the  cox  ’n  can  carry  out  mission  and  talk  on  radio  at  same  time. 

m  Much  greater:  More  info  to  gather  with  a  different  medium.  The  radio  is  the  only  form  of 
comms  needed. 

•  A  little  greater:  You  have  to  wait  for  OIS  to  switch  screens,  then  queue  up  the  case  I  want 
transmitted,  then  send  data  immediately  then  TELL  THE  STATION  I  SENT  THEM  A  CASE 
(on  the  radio). 

•  A  little  greater:  Running  with  a  3-man  crew  gives  the  boat  a  navigator,  helmsman,  and  a 
lookout.  To  take  someone  off  one  of  these  tasks  to  work  OIS  increases  workload. 

•  A  little  greater:  To  operate  OIS  during  a  case  takes  a  crewman  away  from  the  job  at  hand, 
by  using  radio  you  get  info  immediately. 

•  A  little  less:  We  ’re  doing  double  the  work  now  putting  a  case  in  OIS  and  then  have  to  put  it 
in  our  computer  on  base. 

Is  there  anything  else  you'd  like  to  tell  us  about  the  use  of  OIS  for 
transmitting  and  receiving  case  Information? 

•  I  feel  with  a  minimum  crew  of  3,  the  radio  is  much  quicker  and  less  confusing  than  OIS  is 
while  underway. 

•  Stick  to  the  radio  -  you  need  another  crewman  to  do  this  and  another  crewman  can  get  in  the 
way. 

•  Cellular  telephone  is  too  slow  and  unreliable.  Satellite  would  be  much  better. 
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OIS  Questionnaire  4  -  Pen-Based  Computer 
Respondents:  Boarding  Officers,  N=13 

What  do  you  like  best  about  the  pen-based  computer? 

•  Its  ability  to  store  pertinent  information  related  to  cases  and  comms  with  the  OPCEN,  LEIS, 
etc. 

•  The  keypad/typewriter  function,  so  the  system  will  take  the  info,  because  it  doesn’t 
understand  my  handwriting. 

•  Basically  nothing. 

•  The  theory  that  it  will  save  time. 

•  Ido  not  like  the  pen-based  at  all. 

•  Keyboard. 

•  Nothing. 

•  Needed  for  the  future/better  way  of  doing  things. 

•  The  amount  of  features  available. 

•  The  foam  cover. 

•  The  picklists. 

What  do  you  like  least  about  the  pen-based  computer? 

•  Its  relatively  slow  processing  speed,  and  complicated  picklists. 

•  Can ’t  see  it  when  there  is  a  glare,  cumbersome,  affected  by  the  wx,  i.e.  rain,  mist 

•  Reliability  (lack  of)  and  cumbersome  equipment. 

•  Inconsistent  transmit/receive. 

•  Time  it  takes  to  get  it  done. 

•  Everything.  It  is  a  tool  we  do  not  need.  It  makes  our  job  harder  than  it  needs  to  be. 

•  Too  small. 

•  Very  difficult. 

•  Life  of  battery. 

•  Too  complicated,  need  special  training  to  work  pen-based. 

•  Too  much  info  needs  to  be  garnished,  i.e.  some  cases  are  not  so  info  rich. 

•  Takes  too  much  time. 

How  would  you  rate  the  overall  acceptability  of  performance  of  the  pen-based  computer? 

Would  you  say  its  performance  is: _ _ _ 

0  0%  excellent 

3  23%  good 

6  46%  fair  --  why? 

_ 4  31%  unacceptable  "  why? _ 

•  Fair:  Processing  is  slow  (you  wait  a  long  time  when  calling  up  new  screens,  etc.).  Picklists 
esp.  for  LE  boardings  are  too  complicated.  If  the  picklists  were  simpler  (i.e.  resembling  a 
4 100  form)  and  machine  were  faster  the  system  would  be  excellent. 

•  Unacceptable:  It  takes  an  easy  task  and  makes  it  difficult. 

•  Unacceptable:  Too  much  to  take  on  a  vessel  you  are  boarding.  Operator  has  to  concentrate 
too  much  on  pen-based.  Takes  away  from  crew  and  weapon  awareness. 

•  Fair:  Format  is  difficult  to  work  with,  i.e.  should  use  standard  4100  form. 

•  Unacceptable:  Most  people  that  have  been  boarded  say  that  it  takes  too  long. 
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•  Fair:  The  way  the  pen-based  is  set  up  you  have  to  be  a  wizard  to  work  the  system. 
Crewmembers  (BMs  andMKs)  hard  to  get  from  screen  to  screen. 

•  Fair:  Somewhat  slow  and  unreliable.  The  screens  are  different  than  the  shoreside  system. 

•  Unacceptable:  I  think  if  the  pen-based  was  more  like  the  4100  form  it  would  be  more  useful 
and  take  less  time. 


How  do  you  use  the  pen-based  computer?  (check  all  that  apply) 


1  i\/vv  viw  j 

1 

8% 

Not  at  all-l  always  take  data  on  paper  and  never  enter  it  into  the  pen- 
based  computer. 

6 

50% 

I  have  taken  it  with  me  on  boardings  and  entered  boarding  data  directly  into 
the  pen-based  computer  (no  paper). 

How  often  do  you  take  it  on  boardings? 

7  rareiy 

1  sometimes 

0  almost  always 

9 

75% 

I  have  taken  boarding  data  on  paper,  and  then  entered  it  into  the  pen- 
based  computer  when  I  returned  to  my  boat. 

7 

58% 

I  have  used  the  pen-based  computer  to  transmit  boarding  data  from  the 
boat  to  the  station/group. 

1 

8% 

other  (describe) 

•  Have  used  it  on  occasion  during  SAR  cases  to  send  communication  to  the  commcen  and  to 


keep  a  chrono. 

•  I  have  had  to  reenter  data  because  the  pen-based  data  didn 't  arrive  at  the  station  due  to 
comms  problems.  The  case  stayed  at  the  group.  I  had  to  reenter  the  SABR  and  make  another 
4100  form  for  my  records  anyway. 


Answer  the  questions  on  this  page  only  if  you  have  taken  the  pen-based 
computer  on  boardings  (otherwise,  skip  to  the  next  page). 


How  easy  or  difficult  is  it  to  find  the  screens  you  need  to  use? 


1  IWTV 

0 

0% 

very  easy 

7 

54% 

fairly  easy 

4 

31% 

fairly  difficult  -  describe  problems; 

0 

0% 

unacceptably  difficult  -  describe  problems: 

2 

15% 

no  answer 

•  Fairly  difficult:  Often  while  on  one  screen  1  would  need  info  from  another.  Finding  that  info 
takes  a  long  time  (i.e.  date  of  birth  for  FOB),  where  on  a  4100  1  could  just  glance  up  and 
find  it.  If  screens  were  more  consolidated  and  simpler  it  would  solve  this. 


•  Fairly  difficult:  Takes  too  much  time. 

•  Fairly  difficult:  Screens  not  the  same  as  shoreside  and  transmission  is  not  always  reliable. 

How  easy  or  difficult  is  it  to  use  the  pen  to  write  words  and  numbers  on  the  screen? 


0 

0% 

very  easy 

2 

15% 

fairly  easy 

5 

38% 

fairly  difficult  -  describe  problems 

5 

38% 

unacceptably  difficult  -  describe  problems 
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# 


# 

# 


8%  no  answer _ _ _ _ 

Fairly  difficult:  It 's  hard  to  write  a  4100  let  alone  get  a  computer  to  understand  your  writing 
while  bouncing  around. 

Fairly  difficult:  Weather  conditions  hamper  it. 

Fairly  difficult:  It  always  reads  it  as  something  else. 

Fairly  difficult:  Tough  in  rough  weather. 

Unacceptably  difficult:  Doesn ’t  recognize  all  handwriting. 

Unacceptably  difficult:  The  time  I  tried  to  write  the  computer  seldom  recognized  my  writing. 
1  always  use  the  keyboard.  20  min  to  15  min  average  boarding  time. 

Fairly  difficult:  The  pens  used  sometimes  don ’t  work  -  screen  doesn 't  take  input. 
Unacceptably  difficult:  Not  good  enough  to  recognize  everybody 's  hand. 


How  easy  or  difficult  is  it  to  enter  numbers  by  scrolling? 


7 

64% 

very  easy 

4 

36% 

fairly  easy 

0 

0% 

fairly  difficult  ~  describe  probiems 

0 

0% 

unacceptably  difficult  —  describe  problems 

0 

0% 

no  answer 

How  would  you  rate  the  weight  of  the  pen-based  computer? 

1 

8% 

too  light 

9 

75% 

about  the  right  weight 

0 

0% 

a  little  too  heavy 

2 

17% 

moderately  heavy,  but  acceptable 

0 

0% 

unacceptably  heavy 

Have  you  had  any  problem  with  the  following  aspects? 

NO  YES 


Battery  life 

7 

24% 

5 

71% 

Water-proof 

11 

38% 

1 

14% 

Ruggedness 

11 

38% 

1 

14% 

•  Yes,  battery  life:  Battery  life  is  difficult,  it  would  be  great  to  have  an  extended  battery  system. 

•  Yes,  battery  life:  Sometimes  in  the  middle  of  a  boarding  the  pen-based  will  go  out. 

•  Yes,  waterproof-ness:  Can ’t  be  used  when  it  rains.  When  left  on  UTB  the  screen  gets 
moisture  inside  of  it  and  fogs  up. 

•  Yes,  ruggedness:  The  unit  was  dropped  and  the  battery  cover  was  lost  overboard,  but  the 
unit  continued  to  work.  It  seems  to  be  rugged. 

How  could  the  pen-based  computer  be  improved? 

•  (1)  Make  1  or  2  windows  with  only  the  picklists  found  on  a  4100  form,  and  one  screen  for 
supplemental  material  (i.e.  voyage-cargo-comments).  These  items  are  complicated  under  the 
present  setup.  (2)  Give  it  a  faster  processor.  Switching  from  screen  to  screen  takes  a  long 
time. 

•  Somehow  make  the  system  a  one-screen  unit  so  everything  is  on  that  screen.  Also  make  it 
touch  screen. 

•  Continue  to  use  4100 ’s. 

•  Improve  the  screen  so  the  user  can  see  the  data  in  direct  sunlight.  Better  mounting  station. 


A-19 


February  1995 


USCG  Operational  Info  System 


Group/Station  OIS  Testbed  Evaluation  Report 


0  Get  rid  of  it.  Put  a  small  version  of  the  shoreside  OIS  computer  on  the  41  footer.  Use  it  like  a 
police  car.  Pass  the  documentation  to  the  OIS  operator.  BO  does  hoarding  while  boat 
generates  the  report. 

0  By  changing  the  format  to  standard  41 00  and  41 OOS. 

0  You  should  make  it  look  just  like  the  4100  form  and  should  not  be  used  at  all  on  boats  for 
SAR  cases. 

0  Maybe  picklist  with  forms  examp:  4100  etc. 

0  Have  a  mirror  of  the  paper  4100,  including  4100F  and  41  OOS.  Also  a  plain  paper  printout 
format  would  be  good. 

0  Easier  to  use,  quicker. 

0  If  a  screen  came  up  that  looks  just  like  the  4100  form  and  then  you  could  pick  what  section 
you  want  to  go  into  and  fill  out.  Such  as  if  I  had  a  screen  of  the  41 00  form  I  could  see  #  of 
POB  and  put  in  the  number  ofPOB,  then  go  to  personnel  info  without  shifting  screens  it 
would  all  be  there  in  front  of  me  like  the  4100  form. 

Is  there  anything  else  you'd  like  to  tell  us  about  the  pen-based  computer? 

•  The  concept  of  using  the  pen-based  computer  is  excellent  -  it  has  the  potential  of  eliminating 
needless  ops  such  as  entering  boardings  into  SABR  which  could  be  done  directly,  once. 
Most  of  its  features  work  well  and  are  dependable.  The  time  that  is  wasted  u.sing  the 
complicated  picklists,  however,  makes  it  unusable  in  its  present  form.  Many  boaters  have 
made  the  comment  that  the  machine  takes  too  long  -  and  have  said  they  don  V  understand 
why  our  machines  can  Y  operate  more  quickly  like  the  ones  used  by  United  Parcel  Service. 
The  simple  changes  to  the  software  of  consolidated  picklists  etc.  and  faster  speed  wotdd 
solve  those  problems. 

0  Very  difficult  to  see  when  the  sun  is  out.  It  sometimes  jeopardizes  BO  safety  when  you  have 
to  avoid  the  sun  or  glare,  and  this  is  a  self-conscious  move. 

0  It  takes  too  much  time  and  effort  on  board  to  get  information  transmitted  and  received. 
Takes  up  coxswain 's  chart  table  space.  During  a  boarding  too  much  time  is  spent  looking  at 
the  pen-based  and  not  on  the  POBs. 

0  It’s  a  good  idea,  it  just  needs  to  go  back  to  the  drawing  board  for  a  little  while.  You  need  to 
get  a  team  of  BO 's  together  from  the  targeted  area  where  it  will  be  used  and  have  them  give 
you  ideas.  Get  the  E-4 ’s  and  E-5 ’s  that  will  be  using  it,  ask  them  where,  what,  and  how. 

0  Great  idea.  Unit  personnel  need  more  time  to  become  familiar  with  unit  before  using  it  in  the 
field. 

0  1  think  that  if  you  can  not  make  the  screen  look  like  the  4100  form,  they  should  scrap  the 

project. 

0  System  will  work.  Needs  fine  tuning.  Make  it  more  user  friendly. 

0  Good  concept  1  would  be  interested  in  further  exploration  with  this  system  if  improved. 


Blank  Survey  Forms 

The  next  12  pages  present  the  data  collection  forms  used  in  the  objective  measures  portion  of  the 
research,  and  the  blank  survey  forms  used  for  the  subjective  comments  gathering. 
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_ _  SARMIS  Report  Prep 

The  Coast  Guard  R&D  Center  is  developing  a  new  computer  system  (called  CIS)  which  is 
aimed  at  simplifying  the  report  preparation  for  SAR  and  LE  cases.  We  need  to  collect  data  on 
current  reporting  methods  in  order  to  make  comparisons  with  the  new  system.  Please  use  this 
form  to  keep  track  of  your  SARMIS  Reports.  At  the  end  of  each  week,  please  fax  the  form(s) 
to:  Dr.  Anita  Rothblum,  R&DC,  (203)  441-2792. 

Time:  time  taken  to  prepare  one  SARMIS  report  (do  not  count  time  spent  reviewing 
report:  count  only  data  entry  time).  Record  time  in  minutes:  either  write  in  total 
time  (e.g.,  “9”),  or  else  write  in  start/stop  times  (e.g.,  “10:15/10:24”). 


Date 

SAR  Case  # 

Time  to  prepare 
SARMIS  (minutes) 
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Group/Station: 


SITREP  Preparation 


Time  to  prepare  SITREP:  time  taken  to  prepare  one  SITREP  (do  not  count  time  spent 
reviewing  report;  count  only  data  entry  time).  Record  time  in  minutes:  either  write  in  total  time 
(e.g.,  “9”),  or  else  write  in  start/stop  times  (e.g.,  “10:15/10:24"). 


Date 

SAR  Case  or  LE  Boarding 

Time  to  prepare 

SARMIS  (minutes) 

SAR  Case  #  or 

LE  Boarding  # 

Circle 

Type 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 

SAR 

LE 
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The  Coast  Guard  R&D  Center  is  developing  a  new  computer  system  (called  CIS)  which  is 
aimed  at  simplifying  the  report  preparation  for  SAR  and  LE  cases.  We  need  to  collect  data  on 
current  reporting  methods  in  order  to  make  comparisons  with  the  new  system.  Please  use  this 
form  to  keep  track  of  your  SEER  Reports.  At  the  end  of  each  week,  please  fax  the  form(s)  to; 
Dr.  Anita  Rothblum,  R&DC,  (203)  441-2792. 

Report  #:  The  I.D.  number  assigned  to  this  SEER  report. 

LE  Boardings:  Total  number  of  LE  boardings  being  reported  in  one  SEER  report. 

Violations:  Total  number  of  violations  reported  in  the  SEER.  For  example,  if  the  SEER 

discusses  two  boardings,  and  if  one  boarding  resulted  in  two  violations,  and 
a  second  resulted  in  1  violation,  the  total  violations  would  be  “3”. 


Time:  time  taken  to  prepare  one  SEER  report  (do  not  count  time  spent  reviewing  report; 

count  only  data  entry  time).  Record  time  in  minutes:  either  write  in  total  time  (e.g., 
“9"),  or  else  write  in  start/stop  times  (e.g.,  “10:15/10:24”). 


SEER  Total  Number  of  LE  Total  Number  of  Time  (in  minutes)  to 
Date  Report#  Boardings  in  this  Violations  in  prepare 

SEER  report _ this  SEER  report _ this  SEER  report 
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Ad-Hoc  Reports 


Group  Operations  Officer:  Please  tally  the  requests  for  ad-hoc  reports  and  the  labor  required  to  generate 

them. 
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Group/Station:  _ 


SARMiS  Report  Prep  with  OIS 


Please  use  this  form  to  record  time  spent  on  SARMIS  Reports.  At  the  end  of  each  week, 

please  fax  the  form(s)  to:  Dr.  Anita  Rothblum,  R&DC,  (203)  441-2792.  Thanks! 

Time  to  Validate  SAR  Case  in  OIS:  How  long  did  it  take  you  to  validate  this  case?  Start 
counting  when,  after  the  case  is  over,  you  first  click  the  Validate  button.  Stop  counting 
when  OIS  reports,  “Situation  Validated  Successfully!” 

Who  validated  this  case?  Enter  the  name  and  rank  of  the  person  who  validated  this  case  in 
OIS. 

Time  to  transfer  SARMIS  to  OIS:  How  long  did  it  take  you  to  transfer  this  case  to  the 
Standard  Workstation?  Start  when  you  open  the  Report  Controller  to  generate  the 
SARMIS  reports.  End  when  the  Standard  Workstation  program  that  transfers  the  data 
has  finished  running,  and  the  data  is  on  the  Standard  Workstation.  If  you  do  more  than 
one  case  at  a  time,  enter  the  time  required  for  all  of  them,  and  the  range  of  case 
numbers.  We  will  divide  the  total  time  by  the  number  of  cases  to  determine  your 
average  time  per  case. 


OIS 

Time  to 

Who 

Time  to 

Date 

SAR  Case 

Situation 

Validate  SAR 

validated 

transfer  data 

# 

Name 

Case  in  OIS 

this  case? 

to  OIS 
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Time  to  edit  SITREP:  time  taken  to  edit  one  SITREP  generated  by  OiS.  Record  time  in  minutes: 
either  write  in  total  time  (e.g.,  “9”),  or  else  write  in  start/stop  times  (e.g.,  “10:15/10:24”). 
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Group/Station:  _ 


Law  Enforcement  Report  Prep  with  OIS 


PI63S6  US©  this  form  to  rscord  tim©  sp©nt  on  SARMIS  R©ports.  At  th©  ©nd  of  ©sch  w©©k, 

pl©as©  fax  th©  form(s)  to:  Dr.  Anita  Rothblum,  R&DC,  (203)  441-2792.  Thanks! 

Tim©  to  Validat©  this  Boarding  in  OIS:  How  long  did  it  tak©  you  to  validat©  this  boarding? 
Start  counting  whan,  on  th©  shorasid©  systam,  you  first  click  th©  Validat©  button.  Stop 
counting  whan  OIS  raports,  “Situation  Validatad  Succassfully!” 

Who  validated  this  boarding?  Enter  th©  name  and  rank  of  th©  parson  who  validatad  this  case 
in  OIS. 

Tim©  to  transfer  Boarding  to  OIS:  How  long  did  it  tak©  you  to  transfer  this  case  to  th© 
Standard  Workstation?  Start  whan  you  open  th©  Report  Controller  to  generate  th© 
SARMIS  reports.  End  when  th©  Standard  Workstation  program  that  transfers  th©  data 
and  loads  it  into  LEIS  II  has  finished  running,  and  th©  data  is  in  LEIS  II. 
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Group/Station:  _ 


Ad-Hoc  Reports  with  OIS 


Group  Operations  Officer:  Please  tally  the  requests  for  ad-hoc  reports  and  the  labor  required  to  generate 

them. 
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Circle:  NH.  NL,  EN  date: 


Report  Preparation  (Routine) 


Include  routine  reports,  such  as  SARMIS,  LEIS  II,  Abstract  of  Ops,  SAR  case  folders.  Distress  checkoff  sheets, 
SAR  SITREPs,  POLREPs,  Ops  Normal  and  Position  Reports,  MLE  Weekly  Feeder  Report,  Unit  Log,  Chrono  logs. 
Radio  logs.  Underway  Hours  Log,  and  Weather  Log. 


Who?: 

Prepare: 

Review: 

Time: 


job  of  person  who  prepares  or  reviews  the  report  (e.g.,  BO,  GODO,  etc.) 

time  taken  to  enter  data  into  report  forms,  or  to  have  OIS  generate  the  report  for  you. 

time  taken  to  check  over  the  report  for  accuracy  and  completeness  and  correct  any  errors. 


times  in  minutes.  Either  write  in  total  time  (e.g.,  “9"),  or  else  write  in  start/stop  times  (e.g., 
“10:15/10:24"). 
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Circle:  NH,  NL,  EN  date: 


Boat  Crew  Log 


Coll6Ct:  The  time  required  to  write  SAR  or  boerding  data  in  logs,  notebooks,  or  scratch  paper,  includes 
all  case  data  gathered  by  boat  crew. 

Data  from’  person  or  resource  from  who  information  is  collected.  Code  as  follows: 

“GLIS",  “EN",  “NH",  “NL"; 

“Boat”  for  CG  small  boats  from  EN,  NH,  or  NL  only, 

“Other"  for  any  other  CG  resource  (boats  from  other  stations,  helos,  CG  auxiliary)  or  any 
police  or  civilian  resource,  or  the  disabled  vessel. 


SAR  Case  or 

LE  Boarding 

Who? 

(Cox’n,  BO, 
etc.) 

Collect 

Data  from? 
(GLIS,  EN, 

NH,  NL,  Boat, 
Other) 

Time  to 
Collect  Data 

(min;sec) 

SAR  Case#  or 
LE  Boarding# 

circle 

type 

ifLE, 
linked 
to  SAR? 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No  : 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 

SAR 

LE 

Yes  No 
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OIS  Survey  -  Pen-Based  Computer 
(Boarding  Officer  -  POST-OIS) 

□  Job  BO  □  Station _ □.  Date _ □. 


General  Hardware  and  Software 

What  do  you  like  best  about  the  pen-based  computer? 


What  do  you  like  least  about  the  pen-based  computer? 


How  would  you  rate  the  overall  acceptability  of  performance  of  the  pen-based  computer?  Would  you  say 

its  performance  is: 

_ □  excellent 

_ □  good 

_ □  fair  ->  why? 

_ □  unacceptable  ->why? 


How  do  you  use  the  pen-based  computer?  (check  all  that  apply) 

□  Not  at  all-I  always  take  data  on  paper  and  never  enter  it  into  the  pen-based  computer. 

□  I  have  taken  it  with  me  on  boardings  and  entered  boarding  data  directly  into  the  pen-based 

computer  (no  paper). 

How  often  do  you  take  it  on  boardings? 

_ □  almost  always  _ □  sometimes  _ □  rarely 

_ □  I  have  taken  boarding  data  on  paper,  and  then  entered  it  into  the  pen-based  computer  when  I 

returned  to  my  boat. 

□  I  have  used  the  pen-based  computer  to  transmit  boarding  data  from  the  boat  to  the 
station/group. 

_ □  other  (describe) 
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Answer  the  questions  on  this  page  only  if  you  have  taken  the  pen-based  computer  on  boardings 
(otherwise,  skip  to  the  next  page). 

How  easy  or  difficult  is  it  to  find  the  screens  you  need  to  use? 

_ □  very  easy 

_ □  fairly  easy 

_ □  fairly  difficult  describe  problems 

_ □  unacceptably  difficult  describe  problems 


How  easy  or  difficult  is  it  to  use  the  pen  to  write  words  and  numbers  on  the  screen? 

_ □  very  easy 

_ □  fairly  easy 

_ □  feirly  difficult  -»  describe  problems 

_ □  unacceptably  difficult  describe  problems 


How  easy  or  difficult  is  it  to  enter  numbers  by  scrolling? 

_ □  very  easy 

_ □  fairly  easy 

_ □  fairly  difficult  ->  describe  problems 

_ □  unacceptably  difficult  ->  describe  problems 


How  would  you  rate  the  weight  of  the  pen-based  computer? 

_ □  too  light 

_ □  about  the  right  weight 

_ □  a  little  too  heavy 

_ □  moderately  heavy,  but  acceptable 

_ □  imacceptably  heavy 


Have  you  had  any  problem  with; 


Battery  life 

□  no 

□  yes  describe 

Water-proofiiess 

□  no 

□  ves  ->  describe 

Ruggedness 

□  no 

□  ves  describe 
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How  could  the  pen-based  computer  be  improved? 


Is  there  anything  else  you'd  like  to  tell  us  about  the  pen-based  computer? 
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(boat  crews  and  station/group  personnel  -  PRE-  and  POST-OIS) 

Name _ □  Job _ □.  Station _ □.  Date  □ 

How  often  do  you  record  SAR  or  LE  case  information  and-or  prepare  SAR  or  LE  reports? 

_ □  frequently 

_ □  sometimes 

_ □  almost  never  —>  STOP  HERE 


The  rest  of  the  questions  on  this  page  should  be  asked  during  the  PRE-OIS  data  collection. 

(Pre-OIS)  When  you  record  case  or  boarding  information  on  paper  or  forms,  about  how  many  minutes 
does  it  take... 

(a)  for  the  average  SAR  case?  _ □  minutes 

(b)  for  the  average  LE  case?  _ □  minutes 

_ □  n/a--!  don't  perform  this  function 


(Pre-OIS)  About  how  long  does  it  take  to  prepare  the  necessary  SAR  and  LE  reports  at  the  station? 

(a)  for  the  average  SAR  case?  _ □.  minutes 

(b)  for  the  average  LE  case?  _ □.  minutes 

_ □  n/a-I  don't  perform  this  function 


(Pre-OIS)  How  easy  or  difficult  is  it  to  prepare  these  reports? 

_ □  very  easy 

_ □  fairly  easy 

_ □  fairly  difficult  describe  problems 

_ Q  unacceptably  difficult  describe  problems 

_ □  n/a— I  don't  perform  this  function 
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These  questions  should  be  asked  during  the  POST-OIS  data  collection.  The  first  four  questions  (this 
page)  are  for  the  boat  crews;  the  rest  of  the  questions  (next  two  pages)  are  for  all  boat/station/group 
personnel  involved  in  SAR/LE  reporting. 


(boat  crew  only)  On  most  SAR  and  LE  cases,  how  do  you  record  information? 
_ □  into  the  pen-based  computer  only 

_ □  some  info  into  the  computer  &  some  on  paper  ^  which  info/why? 

_ □  only  onto  paper  ->  why  don't  you  use  the  computer? 

_ □  n/a-I  don't  perform  this  function 


(boat  crew  only)  When  you  record  case  or  boarding  information  on  paper  or  forms,  about  how  many 
minutes  does  it  take. . . 

(a)  for  the  average  SAR  case?  _ □  minutes 

(b)  for  the  average  LE  case?  _ □  minutes 

_ □  I  don't  record  data  onto  paper  or  forms;  I  usually  use  the  pen-based 

computer. 

_ □  n/a-I  don't  perform  this  function 


(boat  crew  only)  When  you  record  boarding  data  directly  into  the  pen-based  computer  (that  is,  you  don't 
write  it  on  paper  first),  about  how  long  does  it  take... 

(a)  for  the  average  SAR  case?  _ □  minutes 

(b)  for  the  average  LE  case?  _ □  minutes 

_ □  I  don't  record  data  into  the  computer;  I  usually  use  paper. 

_ □  n/a-I  don't  perform  this  fimction 


(boat  crew  only)  How  easy  or  difficult  is  it  to  transmit  SAR  or  boarding  data  from  the  pen-based 
computer  to  the  OIS  system  at  the  station? 

_ □  very  easy 

_ □  fairly  easy 

_ □  fairly  difficult  ^  describe  problems 

_ □  unacceptably  difficult  describe  problems 

_ □  n/a-I  haven't  done  this 
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All  boat/station/group  personnel  involved  in  SAR/LE  reporting. 


When  SAR  or  boarding  information  has  been  recorded  onto  paper  first,  about  how  long  does  it  take  to 
transcribe  that  information  into  the  computer  (either  on  board  or  at  the  station). 

(a)  for  the  average  SAR  case?  _ □  minutes 

(b)  for  the  average  LE  case?  _ □.  minutes 

_ □  I  usually  record  data  into  the  pen-based  computer,  so  I  don't  need  to  transcribe  it. 

_ □  n/a— I  don't  perform  this  fimction 


How  easy  or  difficult  is  it  to  transcribe  SAR  or  boarding  data  from  paper  forms  into  the  OIS  system  (either 
on  board  or  at  the  station)? 

_ □  very  easy 

_ □.  fiiirlyeasy 

_ n  feirly  difficult  ->  describe  problems 

_ □  unacceptably  difficult  describe  problems 

_ □  n/a-I  haven't  done  this 


How  easy  or  difficult  is  it  to  prepare  reports  using  the  OIS  system? 

_ □  very  easy 

_ □  fairly  easy 

_ □  fairly  difficult  describe  problems 

_ □  unacceptably  difficult  ->  describe  problems 

_ Q  n/a— I  haven't  done  this 


About  how  long  does  it  take  to  use  the  OIS  system  to  prepare  the  necessary  reports. . 

(a)  for  the  average  SAR  case?  _ 0  minutes 

(b)  for  the  average  LE  case?  _ □  minutes 

_ □  n/a— I  don't  perform  this  function 
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How  would  you  compare  the  time  it  takes  to  enter  case  or  boarding  data  and  prepare  reports  using  the  OIS 
system,  compared  to  the  way  you  used  to  do  this? 

_ □  OIS  takes  much  more  time  ->  why? 

_ □  OIS  takes  a  httle  more  time  why? 

_ □  OIS  takes  about  the  same  amount  of  time 

_ n  OIS  takes  a  little  less  time 

□  OIS  takes  much  less  time 


In  your  opinion,  has  the  OIS  system  affected  the  accuracy  of  the  information  in  the  reports? 

_ □  accuracy  has  improved  with  OIS  ->  why? 

_ □  accuracy  is  about  the  same 

_ □  accuracy  is  worse  with  OIS  ->  why? 
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OIS  Survey  -  Command  and  Control 
(all  conunand  center  personnel  -  POST-OIS) 

Name _  □  Job _ □.  Station _ □  Date  □ 


When  you  answer  a  distress  call,  how  do  you  record  the  information? 

_ □  I  type  it  directly  into  the  computer 

_ □  some  info  I  type  into  the  computer  &  some  1  write  on  paper  which  info/why? 

_ □  I  write  it  on  paper  ->  why  not  use  the  computer? 

_ □  n/a--I  don't  perform  this  function 


How  easy  or  difficult  is  it  to  type/transcribe  case  data  into  the  OIS  system? 

_ □  very  easy 

_ □  fairly  easy 

_ □  fairly  difficult  describe  problems 

_ □  unacceptably  difficult  ->  describe  problems 

_ □  n/a--I  haven't  done  this 


How  easy  or  difficult  is  it  to  retrieve  (look  up)  case  data  in  OIS? 

_ □  very  easy 

_ n  fairly  easy 

_ □  fairly  difficult  describe  problems 

_ □  unacceptably  difiScult  describe  problems 

_ □  n/a--I  haven't  done  this 


Do  the  Graphical  Information  System  (GIS--the  electronic  map)  and  OIS  affect  how  quickly  you  can 
identify  and  dispatch  SAR  boats  on  a  case?  Compared  to  the  way  you  operated  previously,  would  you  say 
that  the  time  to  identify  and  dispatch  SAR  boats  is; 

_ □  much  faster  with  GIS/OIS 

_ □  a  little  faster  with  GIS/OIS 

_ □  about  the  same  with  GIS/OIS  as  before 

_ □  a  little  slower  with  GIS/OIS  ->  describe  problems 

_ □  much  slower  with  GIS/OIS  ->  describe  problems 


In  your  opinion,  does  the  OIS  system  affect  the  ease  with  which  case  data  are  updated  and  shared  between 
the  group,  stations,  and  SAR  boats?  Compared  to  the  way  you  operated  previously,  would  you  say  that; 

_ Q  OIS  makes  it  much  more  difficult  to  share  and  update  case  data  ->  why? 

_ □  OIS  makes  it  a  little  more  difficult  to  share  and  update  case  data  why? 

_ n  OIS  doesn't  change  our  ability  to  share  and  update  case  data 
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□  OIS  makes  it  a  little  easier  to  share  and  update  case  data 

□  OIS  makes  it  much  easier  to  share  and  update  case  data 


How  has  OIS  affected  the  number  of  cases  you  can  handle  simultaneously?  Compared  to  the  way  you 
operated  previously,  would  you  say  that  with  OIS,  you  handle: 

_ □  more  cases  simultaneously  than  before? 

_ □  about  the  same  number  of  cases  as  before? 

□  fewer  cases  simultaneously  than  before?  ->  why? 


Do  you  ever  have  more  cases  than  you  can  handle  all  at  once? 

_ □  no 

_ □  yes  ^  what  do  you  do?  Has  OIS  affected  this  in  any  way? 


Is  there  anything  else  you'd  like  us  to  know  about  your  experiences  with  the  OIS  system? 
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OIS  Survey  -  On-Scene  Operations 
(Coxswain  -  POST-OIS) 

Name  _ Q  Job  COXiN  □  Station  □  Date _ □ 


Electronic  Chart 

The  first  few  questions  are  about  the  electronic  chart  (ECDIS)  and  how  it  has  affected  your  navigation 
tasks. 


How  has  the  electronic  chart  (ECDIS)  affected  your  time  to  arrive  on  station^  Compared  to  navigating 
without  ECDIS,  would  you  say  that  with  ECDIS: 

_ □  it  takes  much  less  time  to  arrive  on  station  than  before  why? 

_ □  it  takes  a  little  less  time  to  arrive  on  station  why? 

_ □  it  takes  about  the  same  amount  of  time  as  before 

_ □  it  takes  a  little  more  time  to  arrive  on  station  why? 

_ □  it  takes  much  more  time  to  arrive  on  station  why? 

_ □  n/a— don’t  use  ECDIS 


How  has  the  electronic  chart  (ECDIS)  affected  the  accuracy  of  executing  search  patterns!  Compared  to 
navigating  without  ECDIS,  would  you  say  that  with  ECDIS  search  patterns  are  executed: 

_ □  much  less  accurately  than  before  —>  why? 

_ □  a  little  less  accurately  ->  why? 

_ □  at  about  the  same  accuracy  as  before 

_ □  a  little  more  accurately  why? 

_ □  much  more  accurately  than  before  ->  why? 

_ □  n/a—don't  use  ECDIS 


How  has  the  electronic  chart  (ECDIS)  affected  your  navigational  workload  (that  is,  the  amount  of  time 
and  effort  you  must  devote  to  the  navigation  task)?  Compared  to  navigating  without  ECDIS,  would  you 
say  that  ECDIS: 

_ □  greatly  decreases  your  navigation  workload  — >  why? 

_ □  slightly  decreases  your  navigation  workload  why? 

_ □  neither  decreases  nor  increases  your  workload 

_ □  slightly  increases  your  navigation  workload  why? 

_ □  greatly  increases  your  navigation  workload  why? 

_ □  n/a—don't  use  ECDIS 
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What  do  you  like  best  about  ECDIS? 


What  do  you  like  least  about  ECDIS? 


Data  Transmission  with  OIS 

The  next  set  of  questions  deals  with  using  OIS  to  send  and  receive  case  information  compared  to  using 
the  radio. 

How  do  you  transmit  and  receive  case  information  to  and  from  the  station  or  group  ? 

_ □  Almost  all  information  is  transmitted  and  received  via  OIS. 

□  Some  info  is  via  OIS,  and  some  info  is  via  radio,  i 

_ □%  via  OIS;  □%  via  radio 

What  types  of  info  are  sent  via  OIS  vs.  radio? 

_ □  Almost  all  info  is  via  radio  -»  why  don't  you  use  OIS? 


How  does  OIS  affect  the  time  it  takes  you  to  transmit  and  receive  case  information  (to  and  from  the  station 
or  group)?  Compared  with  using  the  radio,  would  you  say  that  information  transmission  time  with  OIS  is: 

_ n  much  slower  than  using  the  radio  — >  why? 

_ □  a  little  slower  than  using  the  radio  ->  why? 

_ □  about  the  same  as  using  the  radio 

_ □  a  little  faster  than  using  the  radio 

□  much  faster  than  using  the  radio 


How  does  OIS  affect  the  currency  of  the  information  you  receive  (that  is,  do  you  feel  OIS  enables  you  to 
keep  more  up-to-date  on  case  progress)?  Compared  to  using  the  radio,  would  you  say  that  information 
currency  with  OIS  is: 

_ □  much  worse  (less  up-to-date)  than  with  the  radio  why? 

_ □  a  little  worse  than  with  the  radio  — >  why? 

_ □  about  the  same  as  with  the  radio 

_ □  a  little  better  (more  up-to-date)  than  with  the  radio 

_ □  much  better  than  with  the  radio 

How  does  OIS  affect  the  accuracy  of  the  case  data  you  receive  from  the  station/group/other  units? 
Compared  with  using  the  radio,  would  you  say  that  information  accuracy  with  OIS  is. 

_ □  much  more  accurate  than  with  the  radio 
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D  a  little  more  accurate  than  with  the  radio 
D  about  the  same  accuracy  as  with  the  radio 
^  a  little  less  accurate  than  with  the  radio  ->  why? 
□  much  less  accurate  than  with  the  radio  ->  why? 


How  does  using  OIS  for  transmitting/receiving  information  affect  your  workload  (that  is,  the  time  and 
effort  you  devote  to  information  transfer)?  Compared  to  using  the  radio,  would  you  say  that  with  OIS: 

_ □  your  workload  is  much  greater  than  with  the  radio  why? 

_ □  your  workload  is  a  little  greater  than  with  the  radio  why? 

_ □  your  workload  is  about  the  same  as  with  the  radio 

_ □  your  workload  is  a  little  less  than  with  the  radio 

_ □  your  workload  is  much  less  than  with  the  radio 


Is  there  anything  else  you'd  like  to  tell  us  about  the  use  of  OIS  for  transmitting  and  receiving  case 
information? 
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APPENDIX  B:  TECHNICAL  EVALUATION  OF  TESTBED 

SYSTEM 

This  section  provides  a  detailed  technical  assessment  of  the  Phase  One  testbed  system.  It  points 
out  “features”  of  the  testbed  system  which  caused  problems  during  the  testbed,  or  were  design 
compromises  due  to  time  and  money  constraints.  It  draws  on  these  and  the  experiences  of  the 
testbed  to  make  recommendations  for  future  development  of  OIS. 

Data  Model  and  Physical  Database  Design 

Unique  Keys 

Unique  record  keys  were  based  on  data  values,  including  OPFAC  and  Resource  ID.  If  those 
values  changed,  the  unique  key  changed.  If  all  related  records  in  other  tables  were  not  updated, 
the  links  would  be  lost.  Yet  these  links  are  what  give  relational  databases  power.  Generating  a 
data  independent  unique  key  alleviates  this  problem.  Possible  key  values  can  be  generated  from 
date-time  stamps  or  hashing  original  data  values. 

The  OIS  Phase  I  testbed  system  allowed  the  user  to  input  the  vessel  name  on  the  notification 
screen,  but  then  used  this  as  a  part  of  the  'Situation  Name,'  a  nickname  that  could  not  be  changed. 
This  meant  the  user  could  never  change  the  Situation  Name,  even  if  information  was  updated. 
This  made  it  very  hard  to  find  information  later.  The  reason  for  the  inability  to  update  was  that 
this  was  a  key  value.  Future  versions  should  ensure  that  all  keys  are  values  that  the  user  will  have 
no  need  to  update,  and  allow  updating  of  all  values.  Vessel  Name,  and  Person  First  and  Last 
Name  both  suffer  from  this  problem  in  Phase  I. 

Coast  Guard-wide  Cross  Functional  Data  Management 

In  the  Phase  I  OIS  testbed  system,  the  shoreside  system  schema  contained  values  for  both 
Estimated  Length  and  Actual  Length.  LEIS  II  has  an  Actual  Length  value  in  the  Vslinfo  table, 
and  Estimated  Length  value  in  the  Sighting  table.  The  OIS  Phase  I  Pen  application  has  only  one 
value  for  length,  and  a  check  box  indicating  whether  this  is  Estimated  or  Actual.  But  this  scheme 
does  not  support  the  information  required  by  the  legacy  system.  All  modules  of  OIS  should 
support  separate  values  for  Estimated  and  Actual  Length. 

In  the  OIS  Phase  I  testbed  system,  Non-Coast  Guard  Resource  handling  was  clumsy.  This  is 
partly  due  to  a  lack  of  detailed  design  work  in  this  area,  and  partly  because  of  differences  in  the 
way  non-CG  Resources  are  handled  in  SARMIS  and  LEIS  II.  Details  are  described  below.  One 
big  lesson  embodied  here  is  that  no  matter  what  the  mission  (SAR,  LE,  MEP,  RBS,  ....)  the 
USCG  relies  on  and  cooperates  with  external  resources  frequently.  OIS  needs  a  consistent, 
logical  model  for  tracking  our  involvement  with  them  and  for  identifying  their  capabilities  quickly 
and  easily  in  time  of  need.  This  includes  the  Excom  capabilities  in  Phase  I,  Facility  information  in 
MSIS  and  SPEARS,  and  could  potentially  include  other-agency  ELT  resources  (check  with  G- 
OLEonthis).  Now  for  the  detailed  problems  of  Phase  I:  The  non-CG  Resource  Screen  allows 
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creation  of  sorties  that  contain  conflicting  descriptive  info,  and  does  not  contain  the  proper 
SARMIS  picklist  for  non-CG  resource  type.  First,  the  conflicting  descriptions:  A  non-CG 
Resource  is  identified  by  a  CG  OPFAC  number  and  by  a  user-definable  name.  However,  the 
subscreen  currently  allows  the  user  to  describe  this  single  resource  as  being  from  the  USCG 
Auxiliary,  and  the  USCG  Reserve,  and  an  AMVER  vessel,  and  another  government  agency,  all  at 
once  These  various  descriptors  are  in  fact  mutually  exclusive.  We  need  a  way  to  preclude  the 
user  from  entering  illogical  descriptions  of  the  non-CG  resource.  The  best  way  may  be  to  disable 
all  descriptive  sections  of  the  non-CG  Resource  window  until  the  user  selects  resource  type,  then 
enable  the  frame  that  corresponds  to  the  resource  type  chosen.  This  will  increase  accuracy  and 
cut  down  on  user  confusion.  Another  issue  relates  to  picklists.  The  third  frame  on  the  non-CG 
Resource  Screen  contains  three  picklists:  Agency  Type;  Other  Agency;  and  Agency 
Organization,  These  are  all  from  LEIS  II.  There  is  another  important  picklist  from  SARMIS, 
which  also  specifies  ownership  of  the  assisting  non-CG  resource.  It  can  be  found  in  paper  on 
page  C-13  of  the  Red  Book,  COMDTINST  M5230.10A,  but  that  version  of  the  list  is  out-of- 
date.  For  the  actual  list,  use  the  one  found  in  the  code  for  SARMIS/DES  version  2.0.  Obviously, 
we  should  also  display  only  the  appropriate  picklist  for  a  given  sortie.  If  the  sortie  Primary 
Mission  is  SAR,  display  the  SAR  picklist.  If  the  sortie  Primary  Mission  is  ELT,  display  the  ELT 

picklists. 

The  OIS  Phase  I  testbed  system  was  originally  designed  to  generate  the  SARMIS  Assistance 
Request  Number  (ARN)  automatically,  with  no  need  for  the  user  to  track  ARNs.  But  we  quickly 
found  that  since  the  application  provided  no  way  to  tell  whether  a  SARMIS  report  had  been 
generated  for  this  case  before  or  not,  it  was  impossible  to  feasibly  implement  this  since 
SARMIS/DSS  requires  an  unbroken  stream  of  sequential  ARNs  from  each  OPFAC,  Therefore, 
we  added  the  field  ARN  to  the  user  interface  and  had  users  manually  populate  it.  We  did  not  add 
boarding  numbers.  This  experience  points  up  that  for  the  length  of  time  OIS  must  continue  to 
populate  legacy  systems,  it  must  be  sure  it  can  support  all  of  their  rules.  But  since  we  spend  so 
much  time  tracking  ARNs  in  the  current  SARMIS  system  and  in  the  Phase  I  OIS  testbed  system, 
it  is  a  very  important  goal  to  design  future  versions  of  OIS  so  that  they  eliminate  time-consuming 
tracking  requirements.  Ideally,  this  would  be  accomplished  by  integrating  the  information 
requirements  of  all  the  legacy  systems  in  a  single  central  database. 

During  the  OIS  Phase  I  testbed  system,  we  tried  to  integrate  data  fields  between  the  various 
systems  as  much  as  possible.  For  instance,  there  are  three  different  lists  of  Vessel  Types  in  use  in 
the  systems  OIS  supports:  LEIS  II  uses  a  45-item  picklist  called  Vessel  Type,  SARMIS  uses  a  16- 
item  list  called  Vessel  Usage,  and  the  4100  Boarding  Report  has  a  field  called  Use.  OIS  was 
designed  to  derive  this  value  from  the  Law  Enforcement  Vessel  Type,  according  to  a  rule  base 
that  said  'all  ferries  (LEIS  II  code,  MFY)  are  Commercial  Use,’  etc.  This  turned  out  not  to  be  a 
good  place  to  derive,  however,  since  the  Use  field  is  actually  a  very  different  thing  than  Vessel 
Type.  Circumstances  arose  in  which  the  Owner's  use  of  a  vessel  did  not  match  our  prescribed  list. 
For  instance.  Station  New  London  boarded  a  22  foot  outboard  boat  and  called  it  a  Runabout, 
which  was  tme.  So  OIS  classified  this  as  a  Pleasure  boat.  But  it  was  actually  being  used  as  a 
ferry  for  hire  to  transport  people  to  their  boats  at  mooring  buoys  in  the  harbor.  OIS  provided  no 
way  to  override  this. 
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During  the  Phase  I  OIS  testbed  system,  the  pen  application  offered  two  Vessel  Propulsion  fields 
(for  SARMIS  and  the  4100),  while  the  shore  application  and  schema  offered  only  one  (SARMIS). 
This  prevented  the  shore  application  from  being  able  to  print  appropriate  values  for  propulsion 
from  the  shore  system.  In  order  to  fix  this,  we  integrated  the  picklists  and  used  only  one 
integrated  picklist  on  each  platform.  We  removed  the  SARMIS  picklist  from  the  pen  application, 
and  changed  the  label  on  the  other  one  to  simply  'Propulsion  Type,'  removing  the  parenthetical 
'(LE).'  We  used  the  4100  list  as  the  integrated  picklist.  We  also  added  an  eighth  value,  'Other.' 
When  generating  the  Boarding  Report  from  pen  and  from  shore,  we  displayed  the  word  value,  not 
just  the  integer  which  served  as  the  picklist  index.  For  LEIS  II  export,  we  sent  the  word  value 
fi-om  this  list.  For  SARMIS  export,  we  mapped  the  value  in  this  list  to  a  corresponding  value  in 
the  SARMIS  list,  using  the  following  rules: 

4100  list;  SARMIS  list; 

1 - Outboard  01 -Power-Driven 

2- Inboard  Gas  01 -Power-Driven 

3- Inboard  Diesel  01 -Power-Driven 

4- Inboard/Outboard  01 -Power-Driven 

5- Jet  Drive  01 -Power-Driven 

6- Sail  Only  04-Sail 

7- Manual  06-Manually  Propelled 

8- Other  (spec)  02-N/A 

This  whole  situation  highlights  the  need  for  better  integration  between  our  field  systems, 
via  a  single  integrated  central  database.  There  is  currently  a  Data  Administrator  billet  in 
Headquarters,  but  the  office  carries  no  authority  to  mandate  compliance,  and  the  personnel  are 
normally  tasked  with  other  collateral  duties.  Until  the  Coast  Guard  addresses  this  problem,  we 
will  continue  to  have  data  interoperability  problems. 

The  Coast  Guard’s  data  element  naming  standards  must  be  enhanced,  then  used.  There  are  many 
systems  in  the  Coast  Guard  which  share  common  data  elements.  However,  many  are  named 
differently,  have  different  formats,  even  different  data  types.  This  makes  it  very  difficult  to  build 
new  systems,  or  to  aggregate  data  for  corporate  Executive  Support  Systems. 

Enhancements 

Add  a  Track  History  Log  to  the  Shoreside  System  so  that  all  OIS  position  files  are  logged,  and 
can  be  subsequently  recalled  and  displayed  as  tracklines  with  labeled  waypoints.  The  search 
algorithm  for  these  should  allow  the  user  to  specify  a  date/time  range  or  a  lat/long  bounded  box, 
and  display  the  results.  It  should  also  allow  the  user  to  search  for  Resource  Events  (sorties)which 
contain  waypoints  meeting  the  criteria  by  sortie  identifiers  such  as  distressed  vessel  name. 
Boarding  Number,  Unit  Case  Number,  etc. 

In  early  versions  of  the  OIS  Phase  I  testbed  system,  the  mobile  and  shoreside  applications  did  not 
send  position  narratives  back  and  forth.  They  also  did  not  send  remarks  fields,  and  the  shore 
could  not  send  chrono  notes  to  the  pen.  The  net  result  was  that  there  was  not  a  single  free-text 
data  field  or  remarks  field  in  the  whole  application  that  could  be  sent  between  mobile  and 
shoreside  systems.  The  position  narrative  field  was  made  two-way  capable  as  a  workaround. 
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Future  versions  should  ensure  that  chrono  notes  can  be  sent  to  and  from  all  systems.  Also, 
remarks  fields  should  correspond  between  all  modules  of  the  application.  Another  set  of  fields 
that  does  not  get  transmitted  from  on  shore  to  pen  is  in  the  SAR  Summary  table.  A  few  fields  can 
be  sent  from  pen  to  shore:  Cause  of  Incident;  Body  of  Water;  and  Actual  Severity.  This 
imbalance  confuses  users,  and  has  the  potential  to  cause  data  conflicts. 

The  Phase  I  OIS  testbed  system  had  to  impose  a  slight  change  on  several  picklists,  by  adding  a 
■None'  or  'Not  Applicable'  choice.  Sortie  SAR  info;  Rescue  Equipment  Used;  Personnel,  Property 
&  Comms  Assistance  Rendered;  Sortie  Abort  Reason,  Locating  Equipment  Problems,  Rescue 
Equipment  Problems,  Comms  Problems,  Miscellaneous  Problems,  Reason  Search  Suspended. 
Situation  SAR  Info:  Body  of  Water,  Cause  of  Incident.  The  ability  to  enter  a  null  choice  is 
supported  in  these  fields  in  SARMIS/DES,  since  it  allows  the  user  to  skip  them  without  making  a 
choice;  but  the  mechanism  is  slightly  different. 

The  OIS  Phase  I  testbed  system  did  not  have  a  feature  allowing  the  user  to  'merge'  two  Situations. 
This  feature  was  needed  badly  by  users  in  the  testbed  system,  since  many  times  both  the  Group 
and  a  Station  would  begin  data  entry  on  a  case  early  in  its  prosecution.  Once  the  nature  and 
urgency  of  the  case  became  apparent,  one  or  the  other  would  assume  responsibility.  However, 
there  was  no  way  for  the  unit  which  took  responsibility  to  merge  or  import  the  data  which  had 
been  entered  by  the  other,  so  users  would  have  to  manually  re-enter  the  data.  This  was 
compounded  by  the  fact  that  OIS  checks  the  InitialOPFAC  field  in  order  to  assign  responsibility 
for  SAR  case  reporting.  But  in  fact,  initial  OPFAC  may  only  have  been  involved  tangentially.  At 
the  Situation  level  in  the  schema,  responsibility  is  indicated  by  the  SMC  OPFAC. 

Users  need  to  be  able  to  track  the  history  of  who  was  SMC  during  a  SAR  case.  For  this  reason, 
the  OIS  schema  needs  to  be  expanded  to  include  unit  level  information.  It  currently  only  shows 
Situation  level  info  (multi-unit,  multi-mission)  and  Resource  level  info.  OPFAC  level  is  also 
needed,  since  SARMIS  asks  which  unit  was  first  notified  (i.e.,  InitialOPFAC),  and  also  which  unit 
is  'claiidng'  this  case  for  SARMIS  reporting  purposes. 

The  OIS  Phase  I  testbed  system  offered  limited  support  for  describing  non-CG  Resources,  in  two 
separate  places:  The  non-CG  Resource  subscreen  from  the  Sortie  Screen,  and  the  'Excom' 
database.  Early  Phase  II  testbed  systems  replaced  the  Excom  database  with  a  'Facilities'  feature, 
which  is  more  flexible  and  fully  describes  that  the  resource  may  not  just  be  a  SAR  Excom 
resource.  This  feature  must  be  expanded  in  future  versions,  allowing  description  of  resource 
capabilities,  current  position  and  ops,  and  even  an  RDSS  feature  allowing  us  to  track  them  (many 
would  desire  this),  if  they  desired,  via  DSC  or  some  other  open-standard  RDSS  implementation. 
The  resource  section  should  also  provide  access  to  the  facility  information  in  MSIS. 

The  Phase  I  Shoreside  System  allowed  users  to  enter  comments  about  the  system.  The  system 
entered  the  user's  login  name  and  the  name  of  the  screen  from  which  the  comment  was,  and  then 
wrote  those  items  to  an  ASCII  text  file.  These  comments  proved  invaluable  for  feedback,  but 
were  difficult  to  manipulate.  Add  a  date/time  stamp,  and  store  the  comments  in  a  table  in  the 
database  for  easier  manipulation. 
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The  OIS  Phase  I  database  schema  does  not  support  unit  (OPFAC)-level  information,  such  as 
ARN,  Boarding  Number,  etc.  You  can  store  information  at  the  Situation  (multi-OPFAC)  level, 
and  at  the  Sortie  (inside  one  OPFAC)  level,  but  not  for  the  OPFAC.  In  a  fully-developed  OIS, 
sequential  numbers  will  not  be  needed,  but  there  will  still  be  a  need  an  OPF AC-level  table.  One 
field  not  supported  for  this  reason  in  Phase  I  is  Personnel  Resource  Time. 

OIS  systems  that  are  shared  by  more  than  one  OPFAC  (i.e.  GruLIS  and  StaNH)  present 
interesting  challenges.  There  must  be  a  mechanism  for  identifying  which  OPFAC  the  machine  is 
supporting  at  Situation  Create  Time,  and  at  Report  Generate  Time.  Also,  OIS  must  handle  cases 
that  evolve  from  a  single  unit  to  a  multi-unit  case.  Further,  it  must  allow  for  initial  information  on 
a  Situation  to  be  received  by  one  OPFAC  and  entered  into  the  system,  but  then  the  case 
prosecution  and  'claiming'  to  be  credited  to  another  OPFAC. 

Early  versions  of  the  Phase  I  OIS  testbed  system  included  all  Group  units  as  SMC  candidates  in 
the  Situation  SAR  Info  Screen  -  SMC  OPFAC  Picklist.  However,  since  Stations  cannot  be 
designated  as  SMC  for  multi-unit  SAR  cases,  this  was  invalid.  The  testbed  system  therefore 
limited  the  SMC  picklist  to  Groups  and  above.  This  must  be  carried  forward  in  future  versions. 
More  importantly,  OIS  must  support  the  ability  to  pass  the  SMC  designation  from  one  unit  to 
another  at  multiple  points  during  a  SAR  case.  It  must  record  not  only  the  final  designation  of 
SMC,  but  dates  and  times  at  which  SMC  designations  were  passed.  This  is  critical  case 
documentation. 

Early  in  the  Phase  I  testbed  system,  we  transmitted  copies  of  the  entire  CG  Resource  table  with 
each  datagram.  A  significant  challenge  for  the  CG-wide  implementation  of  OIS  is  to  define  the 
rules  by  which  OIS  tracks  the  Coast  Guard’s  dynamically  changing  resource  structure.  This  will 
require  tracking  OPFACs  and  resource  IDs  (Hull  numbers  and  tail  numbers,  and  perhaps 
personnel  ID  and  motor  vehicle  ID).  For  each  Resource,  OIS  must  know  its  permanent  OPFAC, 
and  any  temporary  assignment  (as  in  the  case  where  an  AirSta  help  deploys  aboard  a  cutter).  For 
each  temporary  and  permanent  assignment,  OIS  and  Aops  will  need  to  know  the  time  arrived  and 
departed  that  unit.  The  same  info  needs  apply  to  each  OPFAC,  and  its  ADCON  and  OPCON.  In 
conjunction  with  this  effort,  OIS  must  define  rules  for  how  it  will  make  resource  information 
available  to  command  centers,  operational  planning  staffs,  support  managers,  and  other  entities. 
Managing  our  rapidly  changing  resource  picture  is  critical  to  effectiveness,  but  complicated 
because  the  information  is  protected  at  various  different  levels  and  widespread  geographically. 

During  the  Phase  I  OIS  testbed  system,  the  LEIS  II  Validation  routine  sometimes  reported  that 
'There  is  no  Vessel  record  for  this  Sighting/Boarding.'  What  turned  out  to  be  happening  is  that 
because  of  a  misspelling  in  the  Vessel  Name  on  either  the  Boarding  Screen  or  the  Vessel  Screen, 
OIS  couldn't  find  a  matching  Vessel  record.  We  modified  the  message  to  read:  'OIS  cannot 
identify  a  vessel  which  was  the  subject  of  the  Sighting/Boarding.  This  may  be  because  there  is  no 
vessel  in  the  database,  or  it  may  be  because  of  a  Vessel  Name  mismatch.  If  there  is  a  Vessel 
shown  in  your  database,  be  sure  its  name  exactly  matches  the  names  shown  on  the  Sighting  and 
Boarding  Screens  '  This  highlights  the  need  to  make  sure  the  relationships  between  tables  are 
implemented  in  a  robust  fashion.  Here,  OIS  relied  on  the  user  typing  the  Vessel  Name  into  three 
different  fields  (Vessel  screen.  Sighting  Screen,  and  Boarding  Screen)  exactly  the  same  each  time. 
The  pen  application  solved  this  on  the  Boarding  screen  by  dynamically  building  a  picklist  of  all 
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Vessel  records  involved  in  the  Situation  and  allowing  the  user  to  choose.  Future  versions  must 
handle  this  in  an  easy-to-use,  robust  way. 

The  Person  Screens  (both  pen  and  shore)  allow  you  to  specify  people’s  roles  in  Situations.  The 
Vessel  screen  allows  you  to  specify  the  name  of  the  owner  and  of  the  operator.  But  neither 
updates  the  other.  When  a  person  is  identified  as  owner  or  operator,  that  information  should  be 
copied  to  the  vessel  screen.  Conversely,  when  you  add  an  owner  or  operator  name  on  the  vessel 
screen,  it  should  update  the  person  screen. 

In  the  OIS  Phase  I  testbed  system,  the  pen  application  allows  multiple  violations  of  the  same 
violation  type.  The  shore  system  does  not.  For  4100  violations,  there  should  only  be  one  instance 
of  each  violation.  For  SABR  violations,  however,  there  may  be  many  violations  of  the  same 
type.  This  is  a  design  issue  which  will  require  an  improvement  of  the  way  violations  are  handled. 

Person  Info  Enhancements:  Data  elements  are  not  always  grouped  logically  according  to  the 
user's  world.  In  the  case  of  Vessel  info,  the  following  are  most  commonly  used  and  therefore 
belong  on  the  main  screen:  Hull  Color,  Superstructure  Color,  Length  and  Estimated  Length, 
Vessel  Type  (LE  specific), Vessel  Usage  (SAR),  State  Registration  Number,  Document  Number, 
Flag,  Hailing  Port,  Propulsion  (SAR).  Other  fields  can  be  on  the  appropriate  subscreens.  Also,  a 
logical  tab  order  is  important. 

The  OIS  Phase  I  testbed  system  needed  a  way  to  tell  whether  or  not  a  field  was  null.  The  design 
chosen  included  using  a  value  of to  represent  null.  However,  the  application  code  then  had  to 
explicitly  handle  this  in  all  fields  in  all  circumstances.  This  caused  problems  when  some  of  the 
external  system  interface  code  simply  took  values  from  the  database  without  checking,  then 
inserted  a  negative  number  into  a  character  or  positive  integer  field.  Also,  most  of  the  user- 
readable  reports  printed  these  out  without  checking.  Thus,  each  report  had  many  -1  values,  which 
cluttered  the  page  and  confused  the  user.  Future  versions  need  a  way  of  handling  null  values,  but 
it  must  be  more  consistently  applied.  Ideally,  nulls  should  be  recognized  by  the  DBMS,  so  that 
the  application  doesn't  have  to  implement  its  own  logic. 

The  Phase  I  Shore  and  Mobile  systems  each  handle  Time  CG  Notified  and  Time  Underway 
differently,  and  neither  handles  it  well.  The  first  problem  is  that  the  differences  give  rise  to  data 
conflicts.  The  second  problem  is  that  auto-filling  the  date  and  time  can  lead  to  errors  in  case  and 
sorties  times  if  users  blithely  accept  the  'free'  value,  Instead  of  auto-filling  these  fields,  put  a 
NOW  button  next  to  each  DTG  field  that  inserts  the  current  time,  but  then  lets  you  edit  it  if 
needed.  This  provides  the  best  combination  of  speed  and  usability. 

General  System  Characteristics 

Data  Distribution  Architecture 

The  pen  and  shore  systems  differed  drastically  in  their  approaches  to  storing  and  transmitting 
data.  The  pen  system  used  a  separate  ASCII  text  file  to  store  data  for  each  Resource  Event, 
while  the  shore  used  a  relational  database  manager.  The  data  transfer  was  done  via  ASCII  text 
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files,  with  parsers  on  each  end.  But  since  the  parsers  were  in  C  and  Visual  Basic,  respectively, 
they  were  maintained  separately.  This  gave  rise  to  inconsistencies  unless  configuration 
management  was  bullet  proof.  A  much  better  approach  is  to  use  an  RDDBMS  and  its  embedded 
approach  to  distributing  data.  The  biggest  challenge  to  implementing  this  in  OIS  is  the  fact  that 
that  the  server  must  be  able  to  change  dynamically  from  one  Situation  to  the  next,  much  like  the 
SMC  designation  changes  in  SAR  case  prosecution.  In  CG-wide  implementation,  we  may  also 
want  to  employ  some  sort  of  hierarchical  server  scheme,  to  balance  the  benefits  of  a  single  central 
data  repository  (consistency,  integrity,  ease  of  updates)  against  the  cost,  time  delay  and  load 
balancing  problems  of  sending  everything  to  a  single  server. 

There  are  certain  categories  -of  data  that  are  currently  not  transmitted  fi-om  shore  systems  to 
mobile  systems.  This  includes  some  items  which  are  logical,  such  as  Abstract  of  Operations  data; 
these  items  are  included  in  the  data  elements  which  exist  in  the  shore  schema  but  not  in  the  pen 
schema.  However,  out  of  the  data  elements  which  are  common  to  both  pen  and  shore,  some  still 
cannot  be  transmitted  fi-om  shore  to  pen.  These  are  primarily  resource  event  level  items.  For 
instance.  Boarding  data  can  be  sent  fi-om  pen  to  shore,  but  not  back.  The  same  occurs  for  all  data 
related  to  resource  events.  The  reason  is  that  there  was  significant  potential  for  errors  resulting 
from  one  mobile  unit  getting  a  copy  of  a  record  from  another  mobile  unit,  updating  it,  and  sending 
it  back  to  shore.  The  challenge  here  is  to  define  the  rules  whereby  other  units  can  get  copies  of  a 
Situation,  and  what  parts  they  may  and  may  not  update. 

Archiving,  Retrieval,  and  Data  Management  Issues 

The  Phase  I  testbed  system  allows  users  to  'Archive'  and  'DeArchive'  Situations,  but  only  by 
scrolling  through  a  long  list  of  Situation  names,  which  are  sometimes  meaningless.  Situation 
Management  tools  should  incorporate  the  following  features:  (a)  Allow  users  to  reopen  archived 
Situations  either  because  new  operational  events  have  taken  place  regarding  this  Situation,  for 
regenerating  operational  reports,  or  for  information.  They  should  be  able  to  search  for  archived 
situations  by  vessel  name,  vessel  doc  number,  vessel  state  number,  person  last  name,  OPFAC, 
SAR  Unit  Case  Number,  Boarding  Number,  Violation  Type,  LE  Action  Taken,  or  date  range,  (b) 
Implement  an  enhancement  to  automatically  determine  which  reports  are  required  for  each 
situation  and  generate  them  all  at  once.  Eliminate  the  time-consuming,  manual  step  of  generating 
each  report,  then  logging  in  on  the  CG  Standard  Workstation  to  transfer  it.  (c)  For  this  item, 
'archiving'  refers  not  to  the  classic  definition  of  off-line  storage,  such  as  tape,  but  to  an  on-line 
disk-type  storage  media,  where  it  will  remain  easily  accessible  by  users  but  not  a  part  of  the 
current  operational  database  of 'open'  Situations.  For  performance  reasons,  it  would  be  preferable 
to  store  'archived'  info  in  a  separate  copy  of  the  Situation  database,  not  the  active  copy. 
However,  they  should  remain  on-line  (either  at  the  local  site  or  a  central  site)  for  2  or  3  years,  so 
that  units  can  easily  retrieve  historical  data  for  analysis. 

The  Phase  One  R&D  testbed  system  did  not  handle  archiving  and  retrieval  well.  There  was  a 
rudimentary  archive  mechanism.  In  conjunction  with  future  work  on  the  distributed  data 
architecture,  there  must  be  design  work  done  on  case  management.  How  long  does  the  local  unit 
retain  a  copy  of  complete  records?  Do  they  retain  summary  information  even  longer?  Where  are 
records  stored  permanently?  How  do  field  users  and  headquarters  people  access  archived 
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records?  What  kinds  of  search  tools  will  be  available?  An  easy-to-use  adhoc  query  capability  is 
important.  In  keeping  with  the  principles  of  distributed  systems,  the  user  should  not  need  to  be 
concerned  with  where  the  data  resides;  the  system  should  make  that  chore  transparent. 


System  Administration 

The  OIS  Phase  I  testbed  system  had  several  system  administration  problems.  Users  were  not 
separated  into  categories,  with  various  levels  of  permission.  Instead,  all  had  read-write-execute 
access  to  most  system  files.  Many  system  files  were  initially  kept  in  a  directory  which  also  served 
as  the  repository  for  data  to  be  exported.  However,  the  application  did  not  'clean  up'  after  itself 
by  deleting  these  data  files  after  their  transfer  to  the  CGSW,  so  administrators  had  to  manually 
delete  them.  But  they  sometimes  deleted  system  files  as  well.  Further,  the  system  generates 
validation  files  and  conflict  files  which  are  never  deleted.  Finally,  the  application  creates  4  log 
files  in  the  /h/OIS/comms  directory,  and  the  Progress  database  log  file,  all  of  which  grow  rapidly 
under  regular  use.  Production  versions  of  OIS  must  trim  these  types  of  files  regularly.  This 
problem  has  surfaced  in  LEIS  II,  as  well. 

Updating  software  in  the  testbed  was  easy  for  shoreside  systems,  but  difficult  for  pen-based 
systems.  The  pen-based  systems  were  not  accessible  in  system  administrator  mode  over  the  wide 
area  network.  The  shoreside  systems  were,  however.  The  shoreside  systems  could  be  updated  by 
an  analyst  over  the  network,  saving  substantial  labor  and  travel  costs.  The  pen  computer, 
however,  could  only  be  updated  in  person  by  mailing  disks  or  paying  a  site  visit.  The  advantages 
of  the  remote  capability  were  endless.  Not  just  OIS,  but  all  Coast  Guard  systems,  will  be  able  to 
benefit  from  this  capability. 

OIS  Phase  One  required  that  all  system  management  functions  be  completed  within  the  UNIX 
shell.  This  limits  system  maintenance  to  experienced  programmers  or  administrators.  Many  of 
the  system  management  functions  could  be  consolidated  into  a  single  application  or  module  of 
OIS  and  executed  through  buttons  or  menu  selections,  similar  to  the  way  they  are  implemented  in 
LEIS  II.  This  will  greatly  reduce  the  amount  of  time  required  to  perform  system  maintenance  and 
cut  down  on  the  number  of  errors  that  occur  during  maintenance. 

Early  versions  of  the  Phase  I  OIS  testbed  system  required  that  an  administrator  manually  start  the 
Progress  database  servers  after  a  reboot.  They  were  later  added  to  the  startup  script,  in  order  to 
automate  the  process.  For  ease  of  maintenance,  all  routine  functions  such  as  this  should  be 

automated. 

Help  Systems 

Neither  the  shoreside  system  nor  the  mobile  system  in  the  Phase  I  OIS  testbed  system 
incorporated  any  on-line  help.  They  did  not  even  display  a  brief  message  in  the  status  bar,  as  most 
current  applications  do.  In  many  cases,  especially  for  data  entry,  the  user  interface  design  made 
functions  intuitive  despite  this  lack  of  help.  However,  in  spots  where  the  user  needed  a  little 
prompting  in  order  to  accomplish  a  function,  the  application  proved  very  difficult  to  use,  despite 
extensive  training  and  an  outstanding  User  Manual.  We  even  implemented  a  system  of  peer-level 
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experts  who  were  intended  to  assist  other  users  at  their  units.  But  they  cannot  be  always 
available.  The  lesson  learned  is  that  although  a  help  system  costs  time  and  money  to  develop,  it 
will  pay  off  many  times  over  through  the  life  of  a  system  by  decreasing  training  costs  and  by 
increasing  the  appropriate  use  of  the  system.  Help  systems  should  be  context-sensitive,  enabling 
you  to  get  immediate  help  for  the  current  data  field  or  menu  item.  They  should  include  rich 
sections  of  'See  Also'  related  topics.  They  should  use  hypertext  jumps  and  popup  concept 
definitions  liberally.  They  should  have  large  indices  and  search  topics.  They  should  incorporate 
status  bar  hint  messages,  preferably  straight  from  the  database  schema  where  applicable.  And 
they  should  employ  'balloon'  hints  like  the  current  generation  of  new  GUI  products,  where 
pointing  to  any  screen  object  for  more  than  a  half-second  pops  up  a  small  definition  window. 
Help  systems  should  include  specific  help  for  each  individual  field:  what  the  field  name  means, 
what  format  data  should  be  entered  in,  the  range  of  values  allowed,  and  special  explanatory  notes 
about  the  field.  For  instance,  SARMIS  has  very  detailed  information  about  each  data  element  in 
SARMIS/DES.  This  must  all  be  captured  in  OIS. 

System  Development 

The  OIS  Phase  I  shoreside  application  contains  many  “memory  leaks,”  in  which  memory  is 
allocated  but  never  deallocated.  These  exist  mostly  in  the  user  interface  code,  which  is  C++  and 
X  Windows,  which  are  notorious  for  this  problem.  These  leaks  can  cause  sporadic,  unpredictable 
application  crashes.  In  future  development,  if  the  environment  is  known  for  such  symptoms,  it 
would  be  wise  to  purchase  the  specialized  debugging  tools  which  are  available. 

The  size  of  the  OIS  database  makes  testing  a  lengthy,  complex  process.  Newer  development 
tools  exist  to  automate  a  large  part  of  the  testing  process.  These  would  enhance  development 
productivity  tremendously. 

Communications 

OIS  Phase  One  did  not  provide  an  informal  electronic  mail  or  messaging  system  between  units 
and  resources.  This  capability  is  an  important  coordination  tool. 

Conflict  Handling 

The  command  center  duty  officer  is  primarily  an  information  broker.  The  duty  officer  needs  OIS 
to  provide  tools  to  help  sort  through  the  large  amount  of  data  coming  in,  and  cut  to  the  meat  of 
the  Situation.  Therefore,  when  new  data  is  received  by  any  OIS  system,  it  should  pre-process  the 
data  and  turn  it  into  information  for  the  duty  officer.  Step  1  is  to  see  whether  this  is  a  completely 
new  Situation  or  not.  If  it  is  new,  there  will  be  no  need  for  a  Conflict  Report.  If  it  is  not  new,  the 
system  will  need  to  check  for  conflicts  and  report  them  to  the  user.  Step  2  is  to  notify  the  user 
with  audible  and  visible  alerts.  Both  must  be  noticeable  yet  not  annoying,  since  the  user  may  be 
busy  and  not  want  to  be  interrupted.  Specifically,  users  have  indicated  that  they  don't  want  an 
individual  message  box  alerting  them  to  the  arrival  of  each  update,  but  it  is  important  to  be  able  to 
review  updates  and  handle  them  individually.  Therefore,  there  must  be  one  button,  like  the  one  in 
the  Phase  I  Menu  Bar,  which  indicates  the  presence  of  new  data.  When  the  user  clicks  it,  it 
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presents  a  list  of  all  system  updates  that  have  not  been  viewed  by  the  user.  Each  list  entry  must 
indicate  whether  or  not  there  are  any  conflicts.  They  must  be  presented  chronologically,  and  the 
system  should  not  allow  processing  later  updates  to  any  Situation  before  earlier  updates  for  that 
same  Situation  (check  this  with  a  user  group).  Clicking  on  a  list  entry  must  keep  the  list  box 
open,  and  also  present  a  “New  Data  Summary  Report”  (NDSR).  This  is  Step  3.  The  NDSR  must 
start  with  a  summary  section,  which  presents  Situation  ID,  Location,  and  Situation  Subject  (i.e., 
distressed  vessel  or  subject  person);  SMC;  units  involved;  unit  first  notified;  and  a  brief 
description  of  the  Situation  Subject.  The  second  part  of  the  NDSR  will  be  a  Conflict  List,  which 
lists  each  data  element  in  the  incoming  data  stream  that  conflicts  with  the  value  in  the  local 
database.  This  must  be  presented  as  a  dynamically  built  list  of  data  elements,  organized  by  table. 
The  presentation  must  include  a  fully  understandable  field  label,  then  the  two  data  values  (local 
and  incoming)  (both  presented  in  English,  not  as  a  code).  The  interface  must  present  a  simple 
single-click  method  of  choosing  whether  to  accept  the  local  or  incoming  value.  The  third  part 
consists  of  a  summary  listing  of  new  data,  similar  to  the  conflict  section  except  that  since  there  is 
no  incoming  value,  there's  no  need  to  present  it  or  ask  which  value  to  accept.  Finally,  the  NDSR 
should  provide  quick  access  to  the  situation  summary  report,  perhaps  by  clicking  a  button  on  the 
NDSR,  so  the  user  can  quickly  scroll  down  to  see  other  case  facts  while  reviewing  the  new  data. 
This  is  critical  for  putting  the  new  information  in  the  proper  context. 

The  Phase  I  OIS  testbed  system  handles  incoming  data  safely,  but  not  in  a  fashion  that  makes  it 
easy  for  the  user  to  sift  through  large  amounts  of  information.  One  feature  that  protects  data  is 
called  'Conflict  Reporting.'  When  incoming  data  contains  a  value  that  is  different  than  the  value  in 
the  local  database,  that  value  is  not  inserted  into  the  local  database,  but  flagged  for  user  review. 
Early  versions  of  the  OIS  testbed  system  contained  'negative  reports'  on  data  conflicts.  For 
example,  the  data  conflict  report  for  the  Vessel  Equipment  table  lists  about  15  fields,  taking  up 
nearly  two  screensful,  then  at  the  bottom  says  'No  conflicts  encountered.'  This  detracts  from  the 
user's  ability  to  quickly  process  the  information  OIS  provides.  Review  of  this  and  other  reports 
has  led  to  the  general  rule  that  a  system  for  opcenter  use  should  not  give  negative  reports. 
However,  there  are  exceptions,  such  as  Ops  Normal.  A  typical  Ops  Normal  report  is  actually  a 
negative  report,  saying  'No  Trouble  Here.'  But  we  definitely  want  that  to  come  through. 

The  Phase  I  testbed  system  performed  conflict  checking  on  system-generated  fields  as  well  as 
user-populated  fields.  Therefore,  the  user  sometimes  received  notice  of  a  conflicting  data 
element,  but  had  no  way  to  update  the  data  since  there  was  no  user  interface  field.  Future 
versions  must  avoid  conflict  checking  on  any  field  which  is  not  user-editable.  There  are  other 
fields  that  should  not  be  conflict-checked,  such  as  resource  position  updates;  we  expect  these  to 
change,  so  can  accept  them  as  valid. 


Encryption 

OIS  Phase  I  incorporates  DES-level  encryption  via  software.  All  data  sent  external  to  one 
location,  either  via  landline  or  cellular,  is  encrypted.  This  is  an  important  feature  to  retain  in 
future  versions  of  OIS.  The  Phase  One  encryption  capability  is  file-based:  individual  operating 
system  files  are  encrypted  and  transmitted.  The  Phase  Two  system  will  rely  on  a  distributed 
database  manager  to  handle  data  distribution,  removing  the  application’s  need  to  perform  that 
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function.  But  this  also  removes  its  ability  to  handle  encryption  at  the  file  level.  OIS  will  need  to 
move  to  some  form  of  byte  stream  encryption. 

During  the  Phase  I  OIS  testbed  system,  all  data  transmissions  were  encrypted  using  a  software- 
based  DBS  encryption  module.  The  encryption  modules  were  purchased  off-the-shelf,  and 
consisted  of  object  code  that  our  application  could  use  simply  by  making  function  calls.  The 
product  was  'Secret  Agent,'  by  Information  Security  Corporation.  For  the  most  part,  it  worked 
very  reliably.  However,  datagrams  were  sometimes  not  decrypted  by  the  receiving  system, 
whether  shore  or  mobile.  One  problem  turned  out  to  be  that  in  the  public  key,  we  used  a  date¬ 
time  stamp,  but  one  end  used  a  leading  zero  for  hours  while  the  other  did  not.  After  fixing  that, 
however,  the  problem  still  surfaced  in  approximately  two  percent  of  transmissions  (based  on 
rough  estimates  from  users). 

Remote  Dependent  Surveillance  System 

OIS  Phase  I  implements  RDSS  functionality  in  a  proprietary  fashion.  The  dGPS  unit  sends 
standard  NMEA  0183  sentences,  but  the  ECS  package  used,  MapTech  Pilot,  reads  them  into  a 
proprietary  storage  format.  Phase  I  uses  this  format  rather  than  NMEA  0183  as  its  position 
datagram  format.  Future  releases  should  use  NMEA  0183  sentences. 

In  the  OIS  Phase  I  testbed  system,  the  USCG  Resource  table,  which  contained  position 
information,  was  updated  each  time  a  datagram  was  sent.  This  conflicted  with  the  current 
positions  sent  by  the  boats  themselves.  The  conflicting  records  were  coming  from  old  Resource 
Event  information.  Resource  Event  info,  which  is  historical,  should  never  replace  current  position 
and  ops  information.  But  current  position  and  ops  should  be  easily  updatable  by  the  user.  Also, 
OIS  must  allow  the  user  to  filter  which  resource  types  are  displayed,  and  which  Excom  types 
(non-CG  resources).  These  filters  should  work  by  resource  type,  geographical  area,  and  CG 
organizational  boundaries. 

Routing 

In  early  versions  of  the  OIS  Phase  I  testbed  system.  Situations  which  were  initiated  on  the  mobile 
system  were  not  automatically  sent  to  the  parent  OPFAC.  Therefore,  the  station  may  not  know 
what  its  boat  is  doing.  This  was  corrected  in  later  versions  of  the  testbed  system  by  autorouting 
to  the  parent  OPFAC  of  the  resource.  Future  versions  of  OIS  must  extend  this  by  building  a  list 
of  all  OPFAC  S  and  Resources  involved  in  each  Situation,  with  both  'Action'  and  'Info'  addressees, 
and  autorouting  to  each.  Resource  position  and  ops  info  is  even  more  demanding,  and  not 
Situation-dependent.  Each  command  center  should  have  position  and  ops  info  on  each  resource 
under  its  command,  and  on  each  resource  not  under  its  command  but  within  its  AOR  or  within 
100  miles  of  its  boundaries.  This  information  would  be  provided  automatically  to  all  units 
through  the  OPF AC/Resource  portion  of  the  distributed  database.  Resource  CHOPs  (Changes  of 
Operational  Commander)  are  veiy  dynamic  and  will  be  vital  to  good  resource  management.  To 
illustrate  the  problem,  the  following  is  the  text  of  a  PTR  submitted  during  the  Phase  I  testbed 
system.  Manual  methods  cannot  keep  up  with  this  in  a  production  system:  “Add  the  following 
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boats  to  the  ResourcelD  picklists:  For  New  London,  opfac  0130630:  210531;  For  Eatons  Neck, 
opfac  0130196:  210525.” 

UTB  Communications  Server 

The  Phase  I  testbed  system  only  supported  one  method  of  mobile-to-shore  communications,  via 
the  Electronic  Chart  System  computer  on  board  the  UTB.  This  provided  store  and  forward 
message  capability  for  the  boat.  It  also  made  sure  OPS  NORMAL  reports  always  got  through, 
even  when  the  pen-based  computer  was  undocked,  as  during  a  boarding,  but  it  dramatically 
limited  the  flexibility  of  the  mobile  computer;  it  could  only  be  used  in  conjunction  with  the  UTB. 
In  future  implementations  of  OIS,  the  Boarding  Officer  Module  should  allow  comms  from  any 
location.  This  should  be  available  either  via  standard  CG  data  networks  of  the  future,  or  via  the 
'least  common  denominator,'  the  Public  Switched  Telephone  Network  (including  cellular).  This 
will  maximize  the  utility  of  our  portable  field  worker  infrastructure.  The  Group  Commander  saw 
many  opportunities  for  using  the  pen-based  computer  as  a  completely  portable  unit,  including 
vehicle-based  harbor  checks  and  COTP  functions.  The  data  capture  functionality  and  comms 
functionality  must  be  separable  from  the  ECS  and  OPS  NORMAL  functionality.  This  separation 
was  not  done  well  in  the  Phase  One  system. 

The  comms  server  and  pen-based  computer  were  not  well  integrated,  in  that  they  provided  almost 
no  feedback  to  the  user  about  status  of  communications.  Several  improvements  are  needed  if 
future  versions  of  OIS  use  this  comms  server  approach.  The  functional  requirements  are  vety 
similar  to  those  surrounding  the  arrival  of  new  or  conflicting  information  at  shoreside  systems, 
described  elsewhere.  The  lack  of  feedback  to  small  boat  and  shore  users  created  great  confusion 
concerning  the  status  of  transmitted  messages.  When  the  mobile  computer  connects  to  the  dock, 
the  small  boat  communications  server  should  notify  the  user  if  there  are  messages  from  shore 
waiting  to  be  downloaded  and  provide  an  update  on  the  status  of  messages  sent  to  the  shore.  The 
shore  subsystem  could  receive  update  messages  with  each  OPS  NORMAL  indicating  whether  or 
not  the  mobile  computer  has  downloaded  the  pending  messages. 

Communications  Reliability 

In  the  OIS  Phase  I  testbed  system,  there  was  a  very  high  incidence  (estimated  by  GruLIS  users  at 
ten  percent)  of  data  transfers  that  failed  because  of  'bad  datagrams'  and  'unparseable  records' 
reported  by  the  shore  and  pen  applications,  respectively.  This  was  the  subject  of  extensive 
troubleshooting  and  rework,  and  was  improved  incrementally,  but  was  never  completely  resolved. 
A  design  lesson  for  future  versions  is  to  make  the  various  modules  of  OIS  rely  on  a  distributed 
database  wherever  possible,  letting  the  DBMS  product  do  the  work  of  exporting  and  importing. 
If  that  is  not  possible,  parsers  should  be  written  and  maintained  in  a  conunon  language  on  the 
various  platforms  involved.  The  Phase  I  testbed  system  used  a  shoreside  parser  written  in 
Progress  4GL,  and  a  pen  parser  written  in  Visual  Basic,  so  they  had  to  be  maintained  separately. 
This  resulted  in  extra  developer  workload  and  configuration  management  problems.  The  primary 
symptom  was  crashes  in  the  Parser  and/or  the  Pending  database  when  transferring  multi-line 
remarks  fields.  The  root  problem  was  that  a  Carriage  Return-Line  Feed  character  cannot  be 
stored  in  a  Progress  DBMS  field,  and  cannot  be  handled  in  a  parser  using  Progress  4GL.  The 
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application  code  was  supposed  to  strip  each  CRLF  and  substitute  an  ASCII  255,  but  sometimes 
this  failed. 

During  the  OIS  Phase  I  testbed  system,  data  communications  were  very  unreliable.  In  most 
circumstances,  the  comms  failure  was  not  even  detected  by  the  system  and  reported  to  the  user. 
This  caused  users  great  frustration,  and  is  completely  unacceptable  for  a  production  system.  The 
general  lessons  are  that  (a)  comms  must  be  reliable;  (b)  if  comms  fail  for  some  reason,  at  any 
point  along  the  way,  users  at  both  ends  must  be  notified;  (c)  users  do  not  want  to  see  'data 
successfully  transferred'  messages,  since  they  assume  that  the  message  should  get  through.  They 
only  want  to  know  about  the  occurrences  that  do  not  meet  expectations.  OIS  needs  to  address 
this  not  just  in  the  limited  context  of  point-to-point  messages,  but  from  the  context  of  a  network 
of  distributed  databases,  where  a  transaction  must  be  rolled  back  if  it  cannot  be  completed  at  all 
sites.  For  OIS,  we  should  actually  allow  transactions  at  every  site  that  gets  the  data,  but  queue 
the  failed  transactions  for  committal  to  the  off-line  database  as  soon  as  it  rejoins  the  network. 

Because  communication  between  remote  platforms  is  a  critical  need  in  the  system, 
communications  have  to  be  not  only  reliable  and  robust,  but  if  problems  arise,  they  need  to  be 
quickly  diagnosed  and  resolved.  The  Phase  One  system  relied  on  a  “Queue  Manager”  for 
handling  all  communications-related  tasks.  It  was  a  background  process  that  the  user  did  not 
normally  need  to  be  concerned  with.  However,  when  an  exception  or  error  condition  occurred, 
the  user  had  no  tools  to  assist  in  diagnosing  and  resolving  the  problem.  Future  versions  must 
have  a  module  or  application  that  provides  a  front  end  for  managing  such  a  queue  and  messages 
placed  into  the  queue.  Messages  should  be  able  to  be  added,  deleted,  delayed  and  prioritized. 
Also  included  would  be  a  log  that  shows  the  history  of  messages  and  other  communications 
between  platforms.  The  log  would  show  a  message,  its  current  status  and  what  actions  were 
taken  on  the  message. 

As  a  mission-critical  application,  OIS  will  require  at  least  one  alternate  data  communications  path, 
and  possibly  more.  During  the  testbed,  the  secondary  means  of  communication  was  voice  radio. 
As  OIS  is  relied  upon  more  and  more,  this  would  be  unacceptable. 

OIS  Phase  One  Testbed  relied  on  voice  grade  dial-up  phone  lines  and  modems  for  wide  area 
networking.  This  was  a  high-maintenance,  low-performance  solution  necessitated  by  problems  in 
the  network  design.  The  use  of  more  advanced  transmission  protocols,  such  as  X.25,  for  high¬ 
speed  wide-area  networks  would  greatly  reduce  the  data  communication  times  and 
troubleshooting  and  directly  reduce  the  overall  system  operation  and  maintenance  costs. 


Pen-Based  Application 

OIS  Phase  I  includes  a  Validation  module  as  part  of  the  Shoreside  System.  The  concept  behind 
this  approach  is  that  operations  watchstanders  frequently  do  not  know  all  details  about  a  Situation 
while  it  is  ongoing,  and  cannot  afford  to  be  locked  out  of  any  part  of  the  application  because  of 
that  lack  of  knowledge.  Therefore,  the  OIS  application  allows  you  to  create  a  Vessel  record  with 
as  little  as  the  vessel  name,  or  a  person  record  with  only  a  last  name  and  first  name.  However,  the 
legacy  systems  which  OIS  feeds  have  more  stringent  requirements.  So  after  a  Situation  has  been 
handled,  the  user  runs  a  Validation  routine.  This  applies  the  business  rules  embedded  in  the 
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legacy  systems  to  the  OIS  database  and  prints  a  report  of  the  fields  which  still  need  to  be  filled  in. 
This  exists  only  on  the  Shoreside  System  in  the  Phase  I  testbed  system.  However,  during  LE 
boardings,  the  Boarding  Officer  needs  a  Validation  Tool  in  the  Pen-Based  application.  Since  the 
OIS  Boarding  process  consists  of  12  to  15  screens,  the  BO  needs  a  tool  to  track  boarding 
progress.  This  would  be  run  before  the  receipt  is  printed,  ensuring  that  the  boater  gets  a  complete 
and  accurate  record  of  the  boarding,  and  that  the  record  sent  to  shore  will  be  accurate  also.  We 
should  also  allow  the  user  an  override  button  here,  though,  in  case  there  is  some  legitimate  reason 
that  we  do  not  presently  foresee  that  certain  information  is  not  available.  G-OLE  should  also 
review  this  from  a  policy  perspective:  once  a  boarding  is  complete,  we  may  want  to  disallow  any 
edits  of  that  boarding  report,  except  for  violation  remarks. 

The  Phase  I  testbed  system  has  no  lat/lon  or  position  narrative  on  the  Boarding  Screen.  It  used 
the  position  info  entered  on  the  Notification  Screen,  but  that  caused  great  confusion. 

It  can  be  useful  at  times  for  the  boat  crew  to  have  a  physical  printout  that  summarizes  the  current 
mission  or  assignment.  The  Phase  One  mobile  system  acts  only  as  a  data  entry  device.  To  view 
data  already  input  or  received  from  shore,  the  user  must  page  through  several  screens.  Adding 
the  ability  to  print  a  quick  one  p&g6  report  that  summarizes  the  data  received  so  far  on  a  situation 
would  give  a  hard  copy  capability  to  the  entire  boat  crew.  A  one  page  summary  can  be  viewed 
quickly  to  get  general  information  on  the  situation. 

Early  versions  of  the  Phase  I  OIS  testbed  system  pen  application  printed  a  message  at  the  bottom 
of  the  receipt  when  there  were  no  violations  recorded  during  a  boarding.  It  read, 
'Congratulations!  You  have  no  violations!'  This  was  deleted  for  the  testbed  system,  but  a  similar 
feature  may  be  desired  by  the  program  managers  in  future  versions.  Various  messages  could  print 
out,  depending  on  the  number  and  nature  of  violations. 

Early  versions  of  the  OIS  Phase  I  testbed  system  Pen-Based  Application  had  a  clumsy  save 
mechanism.  The  user  was  forced  to  explicitly  tap  a  button  to  save  data,  instead  of  the  application 
saving  it  automatically.  Further,  when  a  user  saved,  the  application  took  about  20  seconds  to 
unload  the  forms  and  save,  then  returned  to  the  Notification  Screen  after  completing  the  save, 
requiring  that  the  user  navigate  manually  back  to  the  screen  where  they  left  off,  which  takes  10  to 
30  seconds  more.  This  obviously  discouraged  users  from  saving,  not  a  desired  effect.  The  update 
eliminated  the  form  unloading,  and  reduced  save  time  to  less  than  one  second.  But  future 
versions  should  save  automatically  every  time  a  screen  is  opened  or  closed,  as  in  the  shoreside. 
Use  of  database  transactions  will  help  handle  this. 

Mobile  personnel  need  a  quick,  easy  way  to  load  the  current  position.  When  the  user  taps  the 
position  button,  the  application  should  get  the  position  from  the  navigation  sensor,  if  connected, 
or  from  a  local  disk  save  file,  if  disconnected.  The  contact  to  the  navigation  sensor  or  ECS 
computer  should  be  entirely  invisible  to  the  user. 

Violation  Handling 

Handling  of  violations  must  be  improved  in  future  versions  of  both  OIS  and  LEIS  II,  bringing 
them  in  synch  with  the  complete  range  of  regulations  we  enforce.  LEIS  II  offers  a  tiered  system 
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of  violation  description,  but  it  is  implemented  somewhat  clumsily,  with  overly  detailed  categories 
in  some  areas.  It  also  does  not  sort  citations  into  the  various  categories,  although  the  framework 
exists  to  enable  that  capability.  The  OIS  boarding  officer  application  should  present  a  list  of 
regulatory  categories,  with  subordinate  lists  of  citations  in  each  category.  The  application  should 
include  a  remotely  updatable  expert  system  module  which  provides  the  boarding  officer  with  a  list 
of  current  requirements  in  each  category,  and  the  ability  to  point  and  click  to  select  appropriate 
citations.  It  should  also  contain  a  checklist  of  documentary  requirements  for  each  citation  or 
citation  type.  For  instance,  for  a  simple  violation  such  as  insufficient  fire  extinguishers,  a  brief 
comment  a  la  the  4100  S  would  suffice.  For  more  serious  Action  Taken,  such  as  Termination, 
more  detailed  statements  are  required.  For  arrests  and  seizures,  the  boarding  officer  application 
should  maintain  chrono  notes  and  evidentiary  custody  logging. 

Screen  Navigation 

The  OIS  Phase  I  testbed  system  provided  very  little  help  for  the  user  in  knowing  how  far  along  in 
the  boarding  process  they  were.  This  caused  frustration,  and  users  expressed  a  desire  to  have  a 
'real  4100  form'  on  the  computer.  Interviews  revealed  that  what  they  really  wanted  was  a  better 
way  of  knowing  where  they  were  in  the  process,  and  quicker  navigation  between  screens.  One 
common  suggestion  was  to  have  a  single,  scrollable  screen  form. 


Docking  Station 

The  pen-based  computer  was  initially  installed  aboard  the  UTBs  in  a  docking  station.  However, 
the  docking  station  did  not  integrate  well  into  the  workflow  on  the  small  boat.  It  was  located  on 
top  of  the  chart  table,  the  only  flat  surface  in  the  wheelhouse  of  the  UTB.  To  overcome  this,  it 
was  designed  with  a  Plexiglas  cover,  and  was  exactly  the  size  of  the  original  chart  table.  But  you 
could  still  only  use  the  chart  table  for  one  thing  at  a  time.  Also,  it  was  difficult  to  see  the 
computer  screen  since  it  was  mounted  flat.  Finally,  the  connector  design  was  awkward  and 
flimsy.  A  better  design  would  have  the  mobile  computer  mounted  on  an  adjustable  frame  bolted 
to  the  bulkhead,  similar  to  what  is  done  in  police  cars.  A  detachable  keyboard  would  be  mounted 
on  an  independent,  movable  frame.  There  is  not  enough  room  in  the  existing  UTB  cabin  for  an 
adequate  workplace,  but  users  indicated  it  would  not  be  a  problem  to  have  it  mounted  below, 
since  use  is  not  expected  to  be  continuous  over  long  periods  of  time.  As  ECS  and  a  computer 
workstation  are  added  to  the  electronics  complement,  however,  there  should  be  significant 
redesign  of  the  entire  console  to  better  integrate  the  new  components.  Presently,  the  valuable 
space  directly  in  front  of  the  helm  is  taken  up  with  gauges  in  an  inefficient  layout. 

Shoreside  System 

Graphical  User  Interface 

Several  of  the  windows  (screens)  in  the  Phase  I  shoreside  system  are  'modal,'  indicating  that  until 
the  user  exits  that  window,  all  other  windows  are  locked.  However,  the  system  allows  these 
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modal  windows  to  be  hidden  behind  other  windows.  This  is  very  confusing  to  the  user,  and  does 
not  adhere  to  GUI  standards. 

During  complex  cases  or  on  busy  operational  days,  the  watchstander  s  screen  can  become 
cluttered  with  many  windows  and  toolbars  representing  the  different  ongoing  situations.  The 
electronic  chart  quickly  becomes  obscured.  Currently,  it  is  possible  for  the  user  to  hide  all  open 
windows  and  recall  them  quickly.  This  permits  the  watchstander  to  have  a  snapshot  of  the  chart, 
but  it  is  not  possible  to  work  with  the  chart  frequently  in  this  manner.  A  separate  monitor  for  all 
charting  functions,  especially  the  SAR  planning  tool,  is  necessary  to  realize  the  full  benefits  of 
having  an  electronic  chart.  With  the  chart  separate  from  the  work  area,  multiple  command  center 
personnel  can  view  the  entire  scene  on  the  chart  and  have  all  of  the  situation  s  critical  facts 
displayed  simultaneously. 

Chrono  Notes  and  Sortie  Events  (Time  Underway,  On  Scene,  etc.)  are  on  separate  screens  in  the 
Phase  I  testbed  system.  But  these  two  areas  are  where  the  watchstander  spends  the  majority  of 
time  monitoring  case  progress.  Also,  the  Sortie  Times  Screen  was  located  three  screens  deep  off 
a  different  screen  from  Chronos.  Since  Sortie  Events  are  really  a  specialized  case  of 
Chronological  Log  entry,  it  makes  sense  to  combine  these.  The  Phase  II  testbed  system  has  a 
different,  more  integrated  approach  that  will  also  provide  useful  design  feedback.  One  important 
improvement  needed  to  the  Phase  I  Chrono  screen:  It  automatically  timestamps  the  entry  when 
you  create  it.  But  many  entries  are  created  time-late.  The  system  must  allow  the  date  and  time  to 
be  edited  so  that  the  entry  reflects  the  actual  time  of  the  event.  However,  since  paper  log-keeping 
practices  normally  require  time-late  entries  to  be  identified,  this  feature  should  be  reviewed  by  G- 
N  and  G-0  to  see  if  they  also  want  to  retain  the  timestamp  from  when  it  was  actually  created. 

In  several  screens,  there  are  remarks  and  comment  boxes  which  allow  only  two  or  three  lines  of 
text  to  be  displayed  at  a  time.  This  is  usually  insufficient.  Five  lines  is  a  good  number  for  most 
Remarks  boxes. 

Phase  I  Shoreside  System  users  report  that  they  spend  the  majority  of  their  time  in  the  sortie  and 
chrono  notes  screens  while  prosecuting  cases.  This  matches  analysis  of  paper  logs  kept  by 
command  center  watchstanders.  Combine  the  Chrono  and  Sortie  screens.  Move  the  Sortie  Times 
and  Positions  up  from  three  screens  deep  to  the  first  layer  underneath  sortie  ID.  The  new 
combined  screen  will  include  two  lists,  like  the  current  Chrono  and  Sortie  lists,  with  a  detail  box 
for  each  that  shows  a  summary  of  the  currently  selected  item  (like  the  Chrono  screen  works). 

Person  Info  Enhancements:  Data  elements  are  not  always  grouped  logically  according  to  the 
user's  world.  In  the  case  of  Person  info,  the  following  are  most  commonly  used  and  therefore 
belong  on  the  main  screen:  Name  (Last,  First,  Middle);  Which  Vessel  (using  a  picklist  built  from 
vessels  involved  in  this  Situation);  Gender,  Height,  Weight,  Race;  Role;  and  DOB.  Other  fields 
can  be  on  the  appropriate  subscreens.  Also,  a  logical  tab  order  is  important. 

The  Phase  I  Shoreside  user  interface  user  interface  forces  the  user  to  explicitly  deselect  all  items 
currently  in  a  list  before  the  'Create'  (or  'Add')  button  becomes  enabled.  Many  new  users  never 
figure  this  out,  and  are  unable  to  create  new  records  because  of  it.  Most  GUIs  don't  implement 


February  1995 


B-16 


USCG  Operational  Info  System 


Group/Station  OIS  Testbed  Evaluation  Report 


lists  this  way.  Change  future  screens  so  that  the  'Create'  or  'Add'  button  is  enabled  even  when 
another  item  is  selected. 

During  the  OIS  Phase  I  testbed  system,  the  shoreside  system  interface  was  updated  by 
highlighting  the  labels  of  data  fields  that  are  normally  mandatory  in  red.  This  helped  users  quickly 
locate  them.  Future  versions  should  move  these  ffequently-used  fields  to  the  top  level  in  the 
application,  and  arrange  them  more  logically  on  the  screen  and  in  the  tab  order. 

The  OIS  Phase  I  shoreside  testbed  system  allowed  users  to  single-left-click  on  a  chart  object  and 
display  a  single  screen,  such  as  the  vessel  screen  for  a  vessel  involved  in  a  Situation.  This  could 
be  enhanced  greatly  by  using  the  object  or  property  inspector  concepts  in  new-generation  GUI 
applications.  For  instance,  the  user  could  right-click  an  on-screen  vessel  icon  and  pop  up  a  menu 
listing  different  information  or  update  options.  Show  me  all  people  associated  with  this  vessel,  the 
owner,  its  physical  description,  its  SAR  or  LE  or  inspection  history,  etc. 

The  OIS  Phase  I  shoreside  GUI  was  rather  primitive  in  terms  of  picklist  behavior,  tab  order,  etc. 
Future  versions  should  adhere  to  GUI  standards  much  more  fully,  and  take  advantage  of  some  of 
the  innovative  concepts  such  as  tabbed  dialog  boxes,  right-clicking  objects  to  get  a  menu  specific 
to  that  object,  and  toolbars. 

The  OIS  Phase  I  Shoreside  System  created  a  Vessel  record  by  default  at  the  start  of  every 
Situation.  This  was  done  with  the  intention  of  (a)  creating  a  chart  icon  for  the  Situation  and  (b) 
having  the  icon  represent  the  distressed  vessel.  This  proved  problematic,  because  ten  or  twenty 
percent  of  incidents  either  don't  involve  a  vessel,  or  don't  involve  a  vessel  about  which  facts  are 
known.  OIS  definitely  needs  a  chart  icon  representing  each  case,  but  it  should  represent  the 
Situation,  not  the  vessel  involved.  Clicking  on  the  icon  should  bring  up  a  Situation  Summary 
Screen,  indicating  the  missions(s),  incident  type(s),  a  list  of  sorties  (resource  events),  and  a  list  of 
Chrono  notes. 

Data  Entry 

Only  a  minimal  amount  of  range  and  type  checking  is  performed  by  the  data  entry  applications  in 
GRU/STA  OIS.  Additionally,  many  of  the  data  elements  used  by  external  information  systems 
have  restrictions  placed  on  them  based  on  other  data  values.  The  current  logic  waits  until  a  case 
is  validated  before  alerting  the  user.  This  design  was  chosen  in  the  interest  of  making  sure  OIS 
never  disallowed  a  user  from  going  down  a  certain  path  because  of  embedded  rules.  Future  work 
should  embed  more  intelligence  in  the  data  entry  applications,  rolling  some  of  the  validation  logic 
forward  in  time.  Some  things  may  need  to  remain  at  the  end  of  the  process,  but  in  keeping  with 
user  interface  design  principles,  as  much  checking  as  possible  should  be  done  as  early  as  possible 
in  the  process. 

The  data  entry  forms  used  on  the  Shoreside  subsystem  are  organized  by  topic  and  as  a  result,  the 
watchstander  was  frequently  required  to  navigate  through  several  screens  in  order  to  find  a 
certain  data  element.  To  make  the  system  easier  to  use,  many  of  the  data  elements  should  be 
enterable  in  two  different  ways.  The  first  would  be  a  general  data  entry  screen  where  information 
common  to  most  incident  types  is  recorded  along  with  a  text  field  for  a  detailed  narration  and  log 
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entry.  If  any  information  is  gathered  at  the  onset  of  the  situation  that  cannot  be  entered  into  one 
of  the  common  fields,  it  would  be  recorded  into  the  narration  field.  At  a  later  time,  the  data  could 
be  selected,  then  “dragged  and  dropped”  into  the  appropriate  data  entry  fields.  The  second 
method  of  data  entry  would  continue  to  have  the  fields  grouped  by  subject,  (i.e.  vessel,  person, 
resource),  but  have  the  user  interface  guide  the  watchstander,  using  the  “smart  checklist”  concept. 
The  application  would  guide  the  user  through  required  and  optional  items.  It  would  also  present 
questions  for  the  watchstander  to  ask  people  on  scene  to  ensure  as  much  required  information  as 
possible  is  gathered  when  it  is  available. 

Resource  Management 

OIS  must  allow  the  user  to  designate  many  types  of  resources,  including  both  Coast  Guard  and 
non-Coast  Guard.  The  traditional  Coast  Guard  resources,  including  cutters.  Standard  Boats,  and 
aircraft,  must  be  included  along  with  the  wide  range  of  non-standard  boats  vehicles,  personnel 
sorties,  and  other  Coast  Guard  resources.  External  systems  impact  this:  SARMIS  tracks 
information  about  Auxiliary,  Reserve,  and  AMVER  vessels.  Both  SARMIS  and  LEIS  II  track 
information  about  other  federal  agency  involvement,  state  and  local  agencies,  and  foreign 
governments. 

Queries  and  Reports 

The  Phase  I  Situation  Summary  Report  is  unwieldy.  It  takes  several  pages  to  print,  and  dumps 
the  data  from  a  table  in  a  single  column  with  no  formatting  for  ease  of  reading/interpretation.  The 
report  should  be  designed  with  watchstander  input  to  organize  it  into  easily  digested  sections  of 
information.  It  should  include  Chrono  Notes  and  Sortie  Time  in  an  interspersed  chronological 
format,  as  they  are  in  the  Phase  I  SITREP.  The  reports  in  LEIS  II  are  a  useful  starting  point, 
since  they  contain  much  of  the  same  information. 

A  very  time  consuming  task  for  the  watchstander  is  conducting  Precom  and  Excom  phone  calls. 
The  OIS  database  contains  phone  numbers  of  local  marinas,  police  stations,  hospitals  and  other 
Excom  sites.  To  facilitate  these  procedures,  the  watchstander  could  select  sites  to  contact  and 
have  the  OIS  hardware  dial  each  of  them.  The  system  would  then  either  fax  a  request  for 
information,  send  information  on  the  situation,  or  connect  the  watchstander  by  voice  to  the  site. 
An  auto-fax  capability  would  be  very  helpful.  In  addition  to  the  auto-dial  tools,  the  watchstander 
needs  powerful  query  and  report  tools.  These  must  allow  you  to  search  by  geographic  areas, 
lat/long  boundaries,  facility  types,  and  trackline.  The  resultant  report  would  include  some  form  of 
tracking  mechanism  so  the  database  would  know  who  has  been  contacted  and  what  the  results 

were. 

VALIDATION  AND  REPORTS 
External  Systems 

Early  versions  of  the  OIS  Phase  I  testbed  system  built  a  fixed-size  array  to  hold  data  for 
generating  external  reports.  In  some  cases,  the  size  of  this  array  was  only  50  records.  So  when 
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the  unit  conducted  its  fifty-first  LE  boarding,  the  Report  Controller  gave  an  error  message  'array 

subscript  53  out  of  range'  while  the  system  was  building  list  of  situations  to  choose  from.  By  the 

end  of  summer.  Group  LIS  had  over  1,000  situations  in  the  DB.  For  the  testbed  system,  the  fixed 

limit  was  simply  made'larger.  Future  versions  must  not  impose  any  fixed  limit. 

* 

There  is  no  indication  in  Gru/Sta  OIS  of  whether  or  not  a  set  of  case  data  has  been  exported  to 
the  necessary  external  information  systems.  OIS  should  include  an  indication  of  which  external 
systems  have  been  updated  from  this  situation,  when  they  were  updated  and  whether  the  situation 
has  been  modified  since  the  update. 

Early  versions  of  the  Phase  I  OIS  pen-based  application  had  an  error  in  the  way  they  built  data 
files,  which  resulted  in  LEIS II  export  errors.  When  the  pen  application  created  a  Sighting,  it  also 
automatically  created  an  empty  Boarding  record.  Then  the  shoreside  Validation  routine  found  a 
Boarding  record,  and  required  the  user  to  enter  the  rest  of  the  Boarding  data,  even  though  one 
was  not  really  performed. 

The  OIS  Phase  I  testbed  system  suffered  a  large  number  of  schedule  delays  and  errors  related 
directly  to  external  system  interfaces.  The  design  team  did  not  analyze  the  requirements  of  the 
external  systems  adequately,  and  therefore  were  unprepared  for  implementing  the  interface.  This 
is  not  a  new  lesson  in  the  industry,  but  is  worth  restating  here.  Interfaces,  especially  with  older 
systems,  constitute  some  of  the  biggest  challenges  facing  application  developers. 

The  OIS  Phase  I  shoreside  system  required  the  user  to  describe  a  Sortie  by  choosing  a  Sortie 
Type,  an  OPFAC,  and  a  Resource  ID.  In  addition,  for  each  Sortie  where  the  Primary  Mission 
was  SAR,  the  user  had  to  select  Resource  Type.  However,  this  could  easily  be  generated  by  the 
system  for  CG  resources,  since  the  user  just  filled  in  the  Resource  ID. 

The  Phase  I  OIS  testbed  system  learned  an  important  lesson  about  applying  the  business  rules 
embodied  in  external  systems  such  as  LEIS  II  and  SARMIS.  In  several  instances,  those  systems 
have  rules  requiring  that  a  certain  field  be  null.  When  this  is  the  case,  do  not  force  the  user  to 
delete  the  value.  Export  a  null  value  to  the  external  system,  but  allow  the  user-entered  value  to 
remain  in  the  OIS  database.  There  are  several  individual  data  elements  that  fit  this  category. 
Another  excellent  example  that  was  not  fixed  during  Phase  I  is  the  entire  person  record.  LEIS  II 
requires  that  if  a  person  record  is  created,  it  contain  at  least  nine  data  fields.  In  many  cases, 
however,  OIS  users  wanted  to  create  a  person  record  to  track  limited  information  about  a  person 
with  limited  involvement.  The  blanket  imposition  of  the  LEIS  II  mandatory  fields  discouraged 
this,  however,  and  users  learned  to  avoid  putting  person  records  into  the  system  unless  they  had 
to.  A  good  fix  for  this  would  be  to  build  a  list  of  people  at  Validate  time,  with  a  set  of  check 
boxes  next  to  each  record  indicating  whether  or  not  it  should  be  exported  to  the  various  external 
systems.  This  same  concept  applies  to  vessel  records  for  SARMIS. 

In  early  versions  of  the  OIS  Phase  I  testbed  system,  the  concept  of  a  Communications  Sortie  did 
not  exist.  In  Release  1.0,  the  system  was  updated  to  include  Comms  Sorties  as  an  explicit 
Resource  Event  Type  on  the  Sortie  Info  Screen.  This  concept  made  the  SARMIS  export  much 
more  explicit  and  straightforward.  It  will  also  have  value  for  other  mission  areas. 
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The  OIS  Phase  I  testbed  system  did  not  handle  multi-unit  SAR  case  reporting  to  SARMIS 
correctly.  In  a  multi-unit  case,  SARMIS/DSS  requires  a  Unit  Report  for  each  GLIS  OPFAC  that 
was  involved,  including  the  SMC.  Unit  Reports  for  multi-unit  cases  have  A,  C,  and  D  records, 
but  not  B  records.  The  B  record  of  each  Unit  Report  in  a  multi-unit  case  is  filled  with  a  pound 
sign  (#).  The  A  record  for  each  ©PFACs  Unit  Report  contains  three  critically  important 
differentiators  that  are  keys  for  SARMIS/DSS  and  SAR  mainframe:  the  unit  OPFAC,  the  unit's 
ARM,  and  the  MUCNO.  In  addition  to  these  Unit  Reports,  SARMIS/DSS  requires  exactly  one 
SMC  Report  for  each  multi-unit  case.  The  SMC  Report  consists  of  only  an  A  record  and  a  B 
record.  It  has  no  C/D  records,  not  even  the  C/D  record  representing  the  Personnel  Resource 
Time.  That  is  credited  to  the  SMCs  report.  The  OIS  Phase  I  reports  are  incorrect.  This  will 
need  fixing  for  Phase  H,  for  the  interface  to  DSS.  In  the  long  term,  the  future  upgrade  of 
SARMIS  should  adopt  a  scheme  like  the  OIS  Situation  DB,  which  handles  multi-unit  information 

better. 

The  OIS  Phase  I  testbed  system  pen  application  recorded  a  separate  LE  Action  Taken  for  each 
Violation  reported.  On  the  actual  form  CG-4100,  however,  there  is  only  a  single  LE  Action 
Taken  code  for  each  boarding,  not  one  per  violation.  For  future  versions  that  support  Boardings, 
developers  should  consult  with  G-OLE,  G-CJ,  G-NAB,  G-LMI,  and  other  interested  divisions  to 
determine  whether  or  not  they  want  to  change  the  granularity. 

In  the  Phase  I  OIS  testbed  system,  the  database  definition  for  the  field  Violation  Remarks  is 
limited  to  1024  characters.  This  is  insufficient.  It  should  be  an  unlimited  memo  field.  Also,  the 
pen  and  shore  handle  Violation  Remarks  differently.  The  pen  groups  all  Remarks  together,  rather 
than  separating  them  one  per  Violation.  The  shore,  however,  associates  one  Remark  with  each 
Violation  record,  as  you  would  expect.  This  resulted  in  all  Remarks  from  the  pen  coming  ashore 
as  a  group,  and  being  inserted  into  only  one  of  the  Violation  Remarks,  not  all.  There  is  a 
workaround  which  makes  the  Remarks  read-only  on  shore,  requires  all  remarks  to  be  entered  on 
the  pen,  and  prints  out  only  one  set  of  Violation  Remarks  on  the  Boarding  Report  and  for  LEIS 
II.  This  is  obviously  fraught  with  problems,  and  needs  rework  in  future  versions. 

Early  versions  of  the  OIS  Phase  I  testbed  system  did  not  export  State  Registration  Number  to 
SARMIS/DSS.  The  DSS  database  accepts  either  document  number  or  registration  number, 
whichever  is  populated.  This  is  theoretically  never  a  conflict,  since  vessels  are  supposed  to  be 
either  registered  or  documented,  but  not  both.  The  DSS  export  routine  was  enhanced  to  export 
whichever  of  these  is  populated.  If  both  have  values,  OIS  sends  the  document  number. 

In  early  versions  of  the  OIS  Phase  I  testbed  system,  the  SITREP  did  not  include  Sortie  dates  and 
times.  The  report  was  updated  to  include,  for  each  sortie,  all  Sortie  Times  that  were  populated, 
but  not  null  ones.  These  included  Date/Time  Underway,  Began  Searching,  Ended  Search,  On 
Scene,  Departed  Scene,  and  Sortie  Ended.  For  LE,  include  Sighting  Date/Time,  Boarding  Start 
Date/Time,  and  Boarding  End  Date/Time.  These  date/times  are  reported  in  paragraph  2  of  the 
SITREP,  Action  Taken,  along  with  Chrono  Notes.  The  complete  set  of  Times  and  Notes  are 
sorted  in  chronological  order.  In  future  versions,  this  feature  must  be  carried  forward.  It  should 
also  be  enhanced  by  converting  all  alpha  characters  in  Chrono  Notes  fields  to  upper  case.  The 
times/chronos  subreport  should  also  be  copied  into  the  Situation  Summary  Report,  since  it  is  one 
of  the  critical  pieces  of  information  for  users. 
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In  the  Phase  I  OIS  testbed  system,  the  external  reports  generator  module  does  not  check  the  OIS 
data  for  validity  against  the  external  system  format  before  exporting  it.  This  results  in  export 
errors.  The  OIS  database  definition  almost  always  defines  fields  to  be  exactly  the  same  format  as 
their  intended  target.  However,  the  Progress  database  engine  allows  the  OIS  user  interface  to 
insert  values  via  ESQL  that  do  not  match  the  format  defined  in  the  schema.  Future  versions  must 
resolve  this,  preferably  by  using  a  database  engine  that  enforces  format  constraints.  If  that  is  not 
feasible,  the  application  must  check  export  formats  carefully  to  avoid  sending  invalid  values. 

The  OIS  Phase  I  testbed  system  LEIS  II  transfer  module  exports  a  question  mark  for  POB 
birthdate  under  some  circumstances.  It  appears  to  happen  only  when  the  person  in  question  is  the 
owner.  An  Owner  Not  On  Board  record  is  handled  separately  from  other  people  records  on  the 
pen  application.  For  most  people  records,  the  shoreside  Validation  routine  requires  POB 
birthdate,  but  skips  it  for  records  where  the  Role  equals  'Owner.'  This  must  be  fixed  in  future 
versions  that  support  Boardings. 

The  OIS  Phase  I  testbed  system  had  a  misconception  in  the  way  it  built  its  LEIS  II  transfer  files. 
It  generated  a  record  for  the  LEIS  II  'CASCONEG'  table  for  each  boarding  or  sighting.  This  is 
not  appropriate,  since  LEIS  II  actually  uses  the  CASCONEG  table  to  track  groupings  of  sightings 
and/or  boardings  into  a  logical  'case'.  In  fact,  a  CASCONEG  record  indicates  the  equivalent  of  a 
multi-unit  case  for  SARMIS  purposes.  CASCONEG  records  are  created  manually  by  intelligence 
officers  in  the  district  offices.  The  Phase  I  OIS  testbed  system  is  only  capable  of  generating 
single-unit  event  records,  so  it  should  never  generate  a  CASCONEG  record.  During  the  testbed, 
the  CGSW  import  code  was  modified  so  that  it  did  not  actually  create  a  CASCONEG  record  in 
the  database,  but  it  still  used  the  "case. exp'  file  as  a  cornerstone  of  building  the  OIS  export 
records.  This  makes  sense,  since  OIS  is  inherently  a  multi-unit,  multi-mission  system.  However, 
its  usability  was  limited  because  although  the  schema  supports  links  between  multiple  vessels,  the 
people  on  each  vessel,  and  potentially  multiple  sightings  or  boardings  of  each  vessel,  the 
application  code  did  not  follow  those  links  and  generate  boarding  records  accurately  if  there  were 
more  than  one  vessel  involved  in  a  Situation.  Instead,  the  application  code  simply  used  a  Progress 
'FIND  FIRST  Vessel'  statement  to  find  a  vessel  record  matching  the  Situation  key,  but  did  not 
check  to  see  if  it  was  the  vessel  recorded  as  the  subject  of  the  boarding  in  the  Boarding  table.  As 
a  testbed  system  workaround,  it  was  agreed  that  the  easiest  short  term  solution  would  be  to  add  a 
new  Validation  rule  which  checked  to  see  if  this  Situation  involved  one  of  the  ELT  mission  areas, 
then  checked  the  number  of  vessels  involved.  If  the  Situation  involved  ELT,  then  the  Validation 
rule  required  that  you  only  have  a  single  Vessel  record.  This  is  completely  contrary  to  the  OIS 
concept,  however,  and  should  be  modified  in  future  versions.  Situations  which  involve  multiple 
sightings  and/or  boardings  are  then  inherently  LEIS  II  'Cases',  requiring  an  LEIS  II  CASCONEG 
record. 

The  OIS  Phase  I  testbed  system  contained  a  flaw  in  its  generation  of  the  LEIS  II  transfer  file, 
related  to  the  Assist  table.  OIS  sometimes  generated  an  ASSIST  record  for  an  LEIS  II  boarding 
record  even  when  there  was  no  assisting  unit  according  to  LEIS  II  rules.  Rather,  there  may  have 
been  two  OIS  resource  events  because  this  was  an  afler-SAR  boarding,  or  involved  some  other 
resource  event.  This  does  not  constitute  assistance  by  LEIS  II  standards.  LEIS  II  assistance 
records  are  created  when  other  CG  OPFACS,  or  other  agencies,  assist  in  the  actual  boarding.  OIS 
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Phase  1  testbed  system  has  no  way  to  indicate  this,  so  should  not  generate  assistance  records. 
Future  versions  should  implement  a  means  of  supporting  this  LEIS  II  function. 

In  the  Phase  I  OIS  testbed  system,  OIS  generated  LEIS  II  transfer  files  inaccurately  when  there 
were  multiple  vessels  involved.  It  generated  a  single  Boarding  record  with  two  Vessel  records 
associated  with  the  same  EventGroupID.  Only  one  of  them  could  have  been  the  subject  of  a 
single  boarding,  however.  If  both  were  boarded,  they  should  be  exported  as  two  separate 
boardings,  with  different  Event  Group  ID  numbers.  This  is  similar  to  problems  discussed  in  other 

redesign  notes. 

In  the  OIS  Phase  I  testbed  system,  the  database  definition  differed  from  the  target  system 
definition  in  terms  of  format  for  some  fields.  Social  Security  Number,  Phone  Number,  and  Zip 
Code  are  all  commonly  displayed  with  formatting  characters  including  dashes  and  parentheses. 
The  OIS  pen  and  shoreside  applications  displayed  them  differently,  and  exported  them  differently 
to  legacy  systems.  As  a  result,  external  systems  sometimes  received  values  like  '444-5-5-66'  for 
SSAN.  Future  versions  must  export  values  in  the  formats  expected  by  the  target  systems. 

The  OIS  Phase  I  testbed  system  LEIS  II  Export  module  exports  a  record  for  each  person  in  the 
current  Situation,  without  checking  to  see  whether  they  were  aboard  the  Boarded  Vessel  or  not. 
This  can  result  in  invalid  data  being  exported  to  LEIS  II.  Further,  when  OIS  exports  people 
records,  it  does  not  count  them.  Instead,  it  relies  on  the  'Number  of  POB'  field  in  the  Boarding 
table.  Then,  if  the  user  completes  four  person  records  but  enters  a  value  of in  the  'Number  of 
POB'  field,  LEIS  II  only  displays  the  first  person  record.  The  others  exist  in  the  Local  database 
but  are  not  displayed,  apparently  because  the  numPOB  value  is  less  than  the  actual  number  of 
Person  records.  The  Phase  II  testbed  system  will  not  address  boardings,  since  the  mobile  system 
is  intended  for  helicopter  use  only,  but  future  versions  that  support  boardings  must  count  the 
number  of  person  records  and  prompt  the  user  to  check  numPOB  if  that  value  is  less  than  the 
number  of  Person  records  associated  with  this  Vessel  during  this  Boarding. 

In  early  versions  of  the  OIS  Phase  I  testbed  system,  Resource  Events  for  one  mission  area  were 
exported  to  the  legacy  systems  for  other  mission  areas.  For  instance,  ELT  boardings  were 
exported  to  SARMIS.  This  resulted  in  very  inaccurate  records  in  the  legacy  systems.  This  was 
fixed  by  the  end  of  the  Phase  I  testbed  system,  but  the  concept  must  be  extended  as  other  mission 
areas  are  included  in  future  versions  of  OIS. 

The  Phase  I  OIS  testbed  system  has  a  field  for  Personnel  Resource  Time  on  the  Situation  ->  SAR 
Info  Screen.  This  value  is  exported  into  each  resource  event  at  SARMIS  export  time,  because  of 
the  lack  of  an  OPF AC-level  table  in  the  schema.  Further,  The  value  from  the  Situation  ->  SAR 
Info  Screen  should  be  exported  into  a  SARMIS  C/D  record  which  is  created  only  for  Personnel 
Resource  time.  This  particular  C/D  record  is  in  addition  to  the  C/D  records  which  each 
correspond  to  an  OIS  Resource  Event.  Further,  each  SARMIS  C/D  record  is  allowed  to  contain 
a  value  for  personnel  time  expended  by  people  involved  in  this  sortie.  This  is  optional  for  each 
sortie,  and  never  mandatory.  OIS  does  not  need  a  conditional;  test  on  this,  but  does  need  a 
Personnel  Resource  Time  field  on  the  Sortie  ->  SAR  Info  Screen.  This  will  go  into  a  Resource 
Event  level  field  in  the  OIS  schema. 
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Validation 

The  Phase  I  OIS  testbed  system  sometimes  reported  validation  errors  or  conflicts  on  fields  that 
the  user  could  not  update.  This  serves  only  to  fmstrate  the  user.  This  type  of  error  should  be 
trapped  for  and  handled  by  the  application. 

During  the  Phase  I  OIS  Testbed  system,  users  were  confused  by  some  of  the  error  messages.  For 
instance,  Validation  Reports  under  some  circumstances  included  the  message  'the  number  of  POB 
is  less  than  zero,'  with  no  further  information  nor  instructions  on  how  to  correct  the  problem.  This 
message  is  completely  confusing:  a  negative  number  of  POB?  Only  a  computer  could  come  up 
with  that!  All  messages  to  users  must  be  clear  and  specific.  They  should  not  only  describe  what 
problem  has  arisen,  but  more  importantly,  what  the  user  can  do  to  correct  the  problem.  In  this 
case,  the  message  was  changed  to  read,  'The  Number  of  POB  on  the  Situation  Screen  is  blank, 
OR  Total  Lives  Lost  (Situation  ->  SAR  Info  Screen)  is  greater  than  Number  of  POB.'  This  was 
much  more  understandable,  and  cut  down  the  number  of  trouble  calls  dramatically. 

SARMIS  Validation,  Time  Occurred:  The  OIS  Phase  I  testbed  system  has  no  field  in  the 
shoreside  system  interface  or  in  the  database  for  'Time  Incident  Occurred'.  There  is  one  on  the 
pen  and  in  SARMIS.  The  SARMIS  export  routine  populated  this  field  with  the  time  of  the 
creation  of  the  first  resource  event.  Since  resource  events  are  created  after  Notification  Time,  and 
Time  Occurred  is  before  Notification  Time,  this  will  always  create  an  illogical  time  sequence. 
Add  a  field  for  Time  Occurred  (Could  be  placed  on  the  Notification  Screen,  next  to  Initial 
Mission  and  Initial  Incident  Type).  This  must  be  user-updatable. 

The  OIS  Phase  I  testbed  system  uses  a  complex  series  of  IF-THEN-ELSE  statements,  frequently 
nested  several  layers  deep,  to  implement  the  Validation  rules  derived  from  SARMIS  and  LEIS  II. 
Future  versions  of  OIS  should  use  an  expert  system  generator  to  allow  easier  maintenance.  An 
even  more  important  enhancement  would  be  to  implement  the  ability  to  update  remote  software 
sites  over  the  network,  with  no  user/administrator  intervention  at  the  remote  end,  so  that  program 
managers  could  change  business  rules  reflected  in  the  system  more  easily. 

In  some  circumstances,  data  elements  are  legitimately  unknown.  For  instance,  in  an  overdue  case. 
Reported  Lat  and  Long  are  legitimately  unknown  because  its  last  know  position  is  imprecise.  We 
relaxed  the  Validation  rules  affecting  Reported  Lat  and  Long  from  being  mandatory  to  suggestive, 
using  the  statement  'If  you  know  the  Latitude  and  Longitude,  please  enter  them  on  the  Situation 
Screen'.  This  encouraged  the  user  to  fill  them  out  if  possible,  but  if  suggestive  items  were  the  only 
ones  encountered  during  a  Validation  run,  they  would  not  prevent  the  case  from  being  described 
as  Validated. 

The  OIS  Phase  I  testbed  system  had  a  SARMIS  Validation  feature  that  felt  clumsy  to  users. 
SARMIS  requires  a  Reason  Search  Suspended.  If  any  sortie  conducted  a  search,  the  Validation 
Routine  required  a  value  in  the  Reason  Search  Suspended  field.  However,  if  the  Search  was 
actually  successful,  and  the  target  was  located,  there  was  not  really  a  suspension.  Therefore, 
users  felt  that  a  sacred  rule  was  being  violated  by  having  to  put  in  a  reason  for  suspending  the 
search.  Considering  the  gravity  of  a  search  suspension  decision,  this  is  completely 
understandable.  Most  of  the  picklist  choices  actually  had  to  do  with  closing  the  case  rather  than 
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suspending  anyway,  but  the  field  label  caused  concern  for  users.  Future  versions  could  relabel  the 
field,  or  perhaps  not  require  a  value  if  any  sortie  says  'Located.'  But  it  is  more  complex  than  this. 
One  sortie  can  locate  one  of  several  search  objects,  but  there  are  still  other  search  targets  missing, 
and  the  search  could  still  be  suspended.  This  needs  more  work. 

Early  versions  of  the  OIS  testbed  system  allowed  successful  Validation  of  a  situation  involving 
SAR  where  Primary  Response  was  '4'  (meaning  CG  active  duty  sorties  were  launched),  but  there 
were  no  records  in  the  Resource  Event  table  for  that  situation.  This  should  not  be  possible.  If 
priresp  =4,  then  there  must  be  at  least  one  active  duty  SAR  sortie  associated  with  that  situation. 
SARMIS  has  other  Primary  Response  codes  which  should  also  be  mapped  to  their  corresponding 
Resource  Event  types.  For  instance,  if  Primary  Response  is  8  or  9,  then  there  must  be  a  Resource 
Event  involving  a  non-CG  Resource  and/or  a  Comms  Sortie.  This  concept  is  captured  in  the  LE 
Validation  rules:  For  each  Situation  where  the  Incident  Type  is  an  LE  Sighting,  there  must  be  one 
and  only  one  Sighting  record.  The  same  applies  for  Boardings.  As  OIS  is  extended  to  other 
missions,  this  concept  must  apply  to  the  other  mission  areas  as  well. 
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APPENDK  C:  PHASE  I  AND  II  FUNCTIONAL 
DECOMPOSITION 


This  Appendix  consists  of  a  Functional  Decomposition  for  the  Phase  One  and  Two  Operational 
Information  System.  Several  items  contributed  to  this  Functional  Decomposition: 

♦  The  OIS  Phase  I  design  work  and  testbed  system,  as-built. 

♦  The  OIS  Phase  I  business  and  technical  evaluations. 

♦  The  OIS  Phase  II  design  work. 

♦  The  early  phases  of  the  work  done  by  the  Coast  Guard’s  C4I  and  Sensors 
Team,  G-OTT. 

The  Functional  Decomposition  was  developed  using  the  Function  Point  Workbench,  an 
automated  tool  from  Charismatek  Software,  Inc.  It  report  output  is  inserted  in  the  next  nine 

pages. 
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USCG  Operational  Info  System  Application  Development 

FY97RCP  Development  Project 

AC&l  Development 

Level: 

0 

Component: 

USCG  Operational  Info  System 

Label  ID: 

NONE 

Option: 

NONE 

Method: 

All 

COMPONENT  /  TRANSACTION 


1  Manage  Resources 

1 .1  USCGUnits  (OPFACs) 

1.1.1  Create  USCGUnit 

1.1.2  Read  USCGUnit 

1. 1.3  Update  USCGUnit 

1.1.4  Delete  USCGUnit 
1. 15  Fitter  USCG  Units 

1. 1.6  Display  USCG  Units  List  Rpt 

1.1.7  Display  USCG  Units  in  GIS 

1 .2  USCGResources  (incl  Eqpt) 

1.Z  1  Create  USCGResource 

1.2.2  Read  USCGResource 

1.2.3  Update  USCGResource 
1.Z4  Delete  USCGResource 
1.ZS  Filter  USCG  Resources 

1.Z6  Display  USCG  Resource  List  Rpt 
1.Z7  Display  USCG  Resource  in  GIS 

1 .3  OpCon  Relationships  (CHOPS) 

1.3. 1  Create  OpCon  Relationship 

1.3.2  Read  OpCon  Relationship 

1.3.3  Update  OpCon  Relationship 

1.3.4  Delete  OpCon  Relationship 

1.3.5  Filter  OpCon  Relationships 

1.3.6  Display  OpCon  Relations  List 

1.3.7  Display  OpCon  Relations  In  GIS 

1 .4  Non-CG  Resources 

1.4. 1  Create  NorhCG  Resource 

1.4.2  Read  Non-CG  Resource 

1.4.3  Update  Non^G  Resource 

1.4.4  Delete  Non^G  Resource 

1.4.5  Filter  Non-USCG  Resource 

1.4.6  Display  NonCG  Resource  UstRpt 

1.4.7  Display  NonCG  Resources  in  GIS 

1 .5  Crewmembers 

1.5.1  Create  Crewmember 

1.5.2  Read  Crewmember 

1.5.3  Update  Crewmember 

1.5.4  Delete  Crewmember 

1.5.5  Filter  Crewmembers 

1.5.6  Display  Crewmember  List  Rpt 

1 .6  Facilities 

1.6.1  Create  Facility 

1.6.2  Read  Facility 

1.6.3  Update  Facility 

1.6.4  Delete  Facility 

1.6.5  Filter  Facilities 

1.6.6  Display  Facilities  List  Rpt 

1.6. 7  Display  Facilities  in  GIS 


2  Manage  Operations 

2.1  Monitor  Environment 

2.1.1  Monitor  OIS  Resources 

2.1 .1 .1  Contained  in  Manage  Resources 
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2.1 .2  Monitor  non-OlS  Resources 

2. 1 .2. 1  Contained  in  Manage  Resources 

2. 1 .3  Monitor  SARSAT  System 
Z1.3,1  Receive  SARSAT  Aierts 
Z  1.3.2  Create  SARSA  T  Record 
Z1.3.3  Read  SARSAT  Record 
Z  1.3.4  Delete  SARSA  T  Record 
Z  1.3.S  Filter  SARSA  T  Records 
Z1.3.6  Display  SARSAT  List  Report 
Z1.3.7  Display  SARSAT  Hits  In  GIS 

2.2  Receive  &  Process  Information 

2.2.1  Notification  Information 

ZZ 1. 1  Create  Notification  Record 
ZZ1.2  Read  Notification  Record 
ZZ  1.3  Update  Notification  Record 
ZZ  1.4  Delete  Notification  Record 
ZZ1.S  aassify  Notification  as  Case 
ZZ1.6  Classify  Notification  No  Case 
ZZ1.7  Fitter  Notification  Records 
ZZ1.8  Display  Notification  List  Rpt 
ZZ  1.9  Display  Notifications  in  GIS 
ZZ1.10  Archive  Notification  Records 
ZZ1.11  DeArchive  Notification  Records 

2.2.2  Target  Information 

2.2.2. 1  Vessel  Information 
ZZZ1.1  Create  Vessel  Record 
ZZZ1.2  Read  Vessel  Record 
ZZZ  1.3  Update  Vessel  Record 
ZZZ  1.4  Delete  Vessel  Record 
ZZZ  1.5  Filter  Vessel  Records 
ZZZ  1.8  Display  Vessel  List  Report 
ZZZ  1. 7  Display  Vessel  Records  In  GIS 

22.2.2  Person  Information 

ZZZZ1  Create  Person  Record 
ZZZZ2  Read  Person  Record 
ZZZZ3  Update  Person  Record 
ZZZZ4  Delete  Person  Record 
ZZZZS  Filter  Person  Records 
ZZZZ6  Display  Person  List  Report 
ZZZZ7  Display  Persons  In  GIS 

2.2.2.3  Aircraft  Info 

ZZZ3.1  Create  Aircraft  Record 

ZZZ3.2  Read  Aircraft  Record 
ZZZ3.3  Update  Aircraft  Record 
ZZZ3.4  Delete  Aircraft  Record 
ZZZ3.5  Filter  Aircraft  Records 
ZZZ3.8  Display  Aircraft  List  Report 
ZZZ3.7  Display  Aircraft  In  GIS 

2.2.2.4  DMB  Info 

ZZZ4.1  Create  DMB  Record 
ZZZ4.2  Read  DMB  Record 
ZZZ4.3  Update  DMB  Record 
ZZZ4.4  Delete  DMB  Record 
ZZZ4.S  Filter  DMB  Records 
ZZZ4.8  Display  DMB  List  Report 
ZZZ4.7  Display  DMB  Records  in  GIS 
2.22.5  CASP  Target  Info 

ZZZS.1  Create  CASP  Target  Record 
ZZZS.2  Read  CASP  Target  Record 
ZZZS.3  Update  CASP  Target  Record 
ZZZS.4  Delete  CASP  Target  Record 
ZZZS.5  Filter  CASP  Target  Records 
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ZZZS.$  Display  CASE  Targets  Ust  Rpt 
ZZZS.7  Display  CASP  Targets  in  GIS 

222.6  CASP  Location  Info 

ZZZ6.1  Create  CASP  Location  Record 
ZZZS.2  Read  CASP  Location  Record 
ZZZ6.3  Update  CASP  Location  Record 
ZZZ6A  Delete  CASP  Location  Record 
ZZZS.S  Filter  CASP  Location  Record 
ZZZB,6  Display  CASP  Location  List  Rpt 
ZZZB. 7  Display  CASP  Locations  in  GIS 

222.7  CASP  Situation  Info 

ZZZ7.1  Create  CASP  Situation  Record 
ZZZ7.2  Read  CASP  Situation  Record 
ZZZ7.3  Update  CASP  Situation  Record 
ZZZ7.4  Delete  CASP  Situation  Record 
ZZZ7.6  Filter  CASP  Situation  Record 
ZZZ7.B  Display  CASP  Situation  UstRpt 
ZZZ7J  Display  CASP  Situations  in  GIS 

2.2.3  Checklist/QRC  Information 

2.2.3.1  SAR  Checklists 

2.2.3.1 .1  Ck:  Vessel  Taking  Water 
ZZ3.i.L1  Create  Vsl  TOW  Rec 
ZZ3.1.L2  Read  Vsl  TOW  Rec 
ZZ3.1.1.3  Update  Vsl  TOW  Rec 
ZZ3.  LI. 4  Delete  Vsl  TOW  Rec 

2.2.3.1 .2  Ck:  Vessel  Aground 
ZZ3.1.Z1  Create  Vsl  Aground  Record 
ZZ3.1.Z2  Read  Vsl  Aground  Record 
ZZ3.1.Z3  Update  Vsl  Aground  Record 
ZZ3. 1,Z4  Delete  Vsl  Aground  Record 

2.2.3.1 .3  Cl:  Vessel  Capsized 
ZZ3.1.3.1  Create  Vsl  Capsized  Record 
ZZ3. 1.3.2  Read  Vsl  Capsized  Record 
ZZ3. 1.3.3  Update  Vsl  Capsized  Record 
ZZ3.1.3.4  Delete  Vsl  Capsized  Record 

2.2.3.1 .4  Ck:  Vessel  Disabled 
ZZ3.1.4.1  Create  Vsl  Disabled  Record 
ZZ3.1.4.2  Read  Vsl  Disabled  Record 
ZZ3.1.4.3  Update  Vsl  Disabled  Record 
ZZ3.1.4.4  Delete  Vsl  Disabled  Record 

2.2.3.1 .5  Ck:  Vessel  Becalmed 
ZZ3.1.S.1  Create  Vsl  Becalmed  Record 
ZZ3.1.S.2  Read  Vsl  Becalmed  Record 
ZZZ1.S.3  Update  Vsl  Becalmed  Record 
ZZ3.1.S.4  Delete  Vsl  Becalmed  Record 

2.2.3. 1 .6  Ck:  Vessel  Disoriented 
ZZ3.1.B.1  Create  Vsl  Disoriented  Record 
ZZ3. 1.B.2  Read  Vsl  Disoriented  Record 
ZZZ1.B.3  Update  Vsl  Disoriented  Record 
ZZ3. 1.B.4  Delete  Vsl  Disoriented  Record 

2.2.3.1.7  Ck:MEDEVAC 

ZZ3.1.7.1  Create  MEDBVAC  Record 
ZZ3.1.7.2  Read  MBDEVAC  Record 
ZZ3.1.7.3  Update  MBDEVAC  Record 
ZZZ1.7.4  Delete  MBDEVAC  Record 

2.2.3.1.8  Ck:  MEDICO 

ZZ3.1.B.1  Create  MEDICO  Record 
ZZ3.1.B.2  Read  MEDICO  Record 
ZZ3. 1.B.3  Update  MEDICO  Record 
ZZ3. 1.B.4  Delete  MEDICO  Record 

2.2.3. 1.9  Ck:  Flare  Sighting 

ZZ3.1.9.1  Create  Flare  Sighting  Record 
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ZZ3.1,9.2  Read  Flare  Sighting  Record 
ZZ3,1.9.3  Update  Flare  Sighting  Record 
ZZ3.1.9.4  Delete  Flare  Sighting  Record 

2.2.3. MO  Ck:  Vessel  Overdue 

ZZ3.1.10.1  Create  Vsl  Overdue  Record 
ZZ3. 1. 10.2  Read  Vsl  Overdue  Record 
ZZ3. 1. 10.3  Update  Vsl  Overdue  Record 
ZZ3.1.10.4  Delete  Vsl  Overdue  Record 

2.2.3. 1.11  Ck:  Aircraft  Overdue 
ZZ3.1.11.1  Create  Acft  Overdue  Record 
ZZ3.1.11.2  Read  Acft  Overdue  Record 
ZZ3. 1. 11.3  Update  Acft  Overdue  Record 
ZZ3.1.11.4  Delete  Acft  Overdue  Record 

2.2.3. 1.12  Ck:  Diver  In  Distress 
ZZ3.1.1Z1  Create  Diver  Distress  Record 
ZZ3.1.1Z2  Read  Diver  Distress  Record 
ZZ3.1. 1Z3  Update  Diver  Distress  Record 
ZZ3. 1. 1Z4  Delete  Diver  Distress  Record 

2.2.3.1 .13  Ck:  EPIRB  Reports 
ZZ3.1.13.1  Create  EPIRB  Reports 
ZZ3.1.13.2  Read  EPIRB  Reports 
ZZ3.1.13.3  Update  EPIRB  Reports 
ZZ3.1.13.4  Delete  EPIRB  Reports 

2.2.3.1 .14  Ck:  SARSAT  Hit 
ZZ3.1.14.1  Create  SARSAT  Hit 
ZZ3.1.14.2  Read  SARSAT  Hit 
ZZ3.1. 14.3  Update  SARSA  T  Hit 
ZZ3.1. 14.4  Delete  SARSAT  Hit 

2.2.3. 1 .15  Ck:  Person  in  Water 

ZZ3.1.1S.1  Create  Person  in  Water  Record 
ZZ3. 1. 1S.2  Read  Person  in  Water  Record 
ZZ3. 1. 1S.3  Up€late  Person  in  Water  Record 
ZZ3. 1. 1S.4  Delete  Person  In  Water  Record 

2.2.3. 1 .16  Ck:  Vessel  Stuck  in  Ice 
ZZ3.1.16.1  Create  Vsl  Stuck  In  Ice  Record 
ZZ3.1.16.2  Read  Vsl  Stuck  in  Ice  Record 
ZZ3.1.16.3  Update  Vsl  Stuck  In  Ice  Record 
ZZ3. 1. 16.4  Delete  Vsl  Stuck  In  Ice  Record 

2.2.3. 1.17  Ck:  Vessel  Collision 

ZZ3. 1.17.1  Create  Vsl  Collision  Record 
ZZ3.1.17.2  Read  Vsl  Collision  Record 
ZZ3.1.17.3  Update  Vsl  Collision  Record 
ZZ3.1.17.4  Delete  Vsl  Collision  Record 

2.2.3.1 .18  Ck:  Vessel  Fire 

ZZ3.1.16.1  Create  Vsl  Fire  Record 

ZZ3.1.18.2  Read  Vsl  Fire  Record 
ZZ3.1.18.3  Update  Vsl  Fire  Record 
ZZ3.1.18.4  Delete  Vsl  Fire  Record 

2.2.3.2  ELT  Checklists 

2.2.3.2.1  Ck:  Zero  Tolerance 

ZZ3.Z1.1  Create  Zero  Tolerance  Record 
ZZ3.Z  1.2  Read  Zero  Tolerance  Record 
ZZ3.Z1.3  Update  Zero  Tolerance  Record 
ZZ3.Z  1.4  Delete  Zero  Tolerance  Record 

2.2.3  2.2  Ck:  Vessel  Seizure 
ZZ3.ZZ1  Create  Vsl  Seizure  Record 
ZZ3.ZZ2  Read  Vsl  Seizure  Record 
ZZ3.ZZ3  Update  Vsl  Seizure  Record 
ZZ3.ZZ4  Delete  Vsl  Seizure  Record 

2.2.3.2.3  Ck:  Marine  Mammal  Incident 
ZZ3.Z3. 1  Create  Marine  Mammal  Record 
ZZ3.Z3.2  Read  Marine  Mammal  Record 
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ZZ3.Z3.3  Update  Marine  Mammal  Record 
ZZ3.Z3.4  Delete  Marine  Mammal  Record 

2.2.3.2.4  Ck:  PD27  Process 

ZZ3.Z4.1  Create  PD27  Process  Record 
ZZ3.Z4.2  Read  PD27  Process  Record 
ZZ3.Z4,3  Update  PD77  Process  Record 
ZZ3.Z4.4  Delete  PD27  Process  Record 

2.2.3.2.5  Ck:  Border  Search  Authority 
ZZ3.ZS.1  Create  Border  Search  Record 
ZZ3.ZS.2  Read  Border  Search  Record 
ZZ3.ZS.3  Update  Border  Search  Record 
ZZ3.ZS.4  Delete  Border  Search  Record 

2.2.3.2.6  Ck:  AMIO  Incident 

ZZ3.Z6. 1  Create  AMIO  Incident  Record 
ZZ3.Z6,2  Read  AMIO  Incident  Record 
ZZ3.Z6.3  Update  AMIO  Incident  Record 
ZZ3.Z$.4  Delete  AMIO  Incident  Record 

2.2.3.3  General  Cmd  Ctr  Checklists 
2.2.3.3.1  Ck:Exploslve  Ordnance  Disposal 

ZZ3.3.1.1  Create  EOD  Record 
ZZ3.3. 1.2  Read  EOD  Record 
ZZ3.3. 1.3  Update  EOD  Record 
ZZ3.3.1.4  Delete  EOD  Record 
2.2.3.32  Ck:  Asylum  Requests 

ZZ3.3.Z  1  Create  Asylum  Request  Record 
ZZ3.3.Z2  Read  Asylum  Request  Record 
ZZ3.3.Z3  Update  Asylum  Request  Record 
ZZ3.3.Z4  Delete  Asylum  Request  Record 

22.3.3.3  Ck:  Oil  Pollution  Reports 
ZZ3.3.3.1  Create  Oil  Pollution  Record 
ZZ3.3.3.2  Read  Oil  Pollution  Record 
ZZ3.3.3.3  Update  Oil  Pollution  Record 
ZZ3.3.3.4  Delete  Oil  Pollution  Record 

2.2.3.3  4  Ck:  HazMat  Reports 

ZZ3.3.4. 1  Create  HazMat  Report  Record 
ZZ3.3.4.2  Read  HazMat  Report  Record 
ZZ3.3.4.3  Update  HazMat  Report  Record 
ZZ3.3.4.4  Delete  HazMat  Report  Record 

2.2.3  4  Boat  Ops  Checklists 
ZZ3.4.1  Crew  Brief 
ZZ3.4.2  Passenger  Brief 
ZZ3.4.3  Medical  Debrief 
ZZ3.4.4  Survivor  Debrief 
ZZ3.4.6  Rescue  Brief 
ZZ3.4.9  Dewatering  Checklist 
ZZ3.4.7  Firefighting  Checklist 

2.2.3.S  Actt  Ops  Checklists 
ZZ3.S.1  Pre-flight  Checklist 
ZZ3.S.2  Post-Eight  Checklist 
ZZ3.S.3  Approach  Brief 
ZZ3.S.4  Hoist  Brief 
ZZ3.S.6  PATCH  Brief 
ZZ3.5.6  MATCH  Brief 

2.2.3.5.7  Crew  Brief 

2.2.3.5.8  Passenger  Brief 

2.2.3.5.9  Medical  Debrief 

2.2.3.5.10  Survivor  Debrief 

2.2.3.5.1 1  Rescue  Briefing 

2.2.3.5.1 2  Emergency  Action  Checklist 

2.2.4  Reference 

2.2.4. 1  Official  Policy  Information 

ZZ4.1.1  Import  ASai  Text  of  Policy 
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ZZ4. 1.2  Create  Index  Entry  for  Policy 
ZZ4. 1.3  Search  Policy  index 
ZZ4.1.4  Display  ASCII  Text  of  Policy 
2  2.4.2  Local  Guidance  (Hotword) 

ZZ4.Z1  Import  ASai  Text  of  Hotword 
ZZ4.Z2  Direct  Hotword  Data  Entry 
ZZ4.Z3  Create  Index  Entry  for  Hotword 
ZZ4.Z4  Search  Hotword  Index 
ZZ4.ZS  Display  ASCII  Text  of  Hotword 
2.2.5  Weather 

ZZS.  1  Create  Weather  Record 
ZZ6.2  Read  Weather  Record 
ZZS.3  Update  Weather  Record 
ZZ6.4  Delete  Weather  Record 
ZZS.S  Filter  Weather  Records 
ZZS.6  Display  Weather  List  Report 
Z2.S.  7  Display  Weather  Records  in  GIS 

2.3  Analyze  Information:  Reports 

Z3.1  Display/Print  Situation  Summ 
Z3.2  Display/Print  Critical  Info 
Z3.3  Display/Print  New  Data 
Z3.4  Display/Print  Changes 
Z3.S  Display/Print  Data  Conflicts 
Z3.6  Display/Print  Resource  Status 
Z3J  Display/Print  Active  Sit  Ust 
Z3.8  Display/Print  Sit  Summ  Report 
Z3.9  Adhoc  Query  Active/Archived 

2.4  Plan  Operation 

Z4.1  Assign  SMC/MC 

2.4.2  Create  Search  Area 
Z4.Z  1  Select  Targets 
Z4.Z2  Define  Search  Area 
Z4.Z3  Create  Search  Area  Record 
Z4.Z4  Read  Search  Area  Record 
Z4.ZS  Update  Search  Area  Record 
Z4.Z6  Delete  Search  Area  Record 
Z4.Z7  Filter  Search  Area  Records 
Z4.Z8  Display  Search  Areas  Ust  Rpt 
Z4.Z9  Display  Search  Areas  in  GIS 

2.4.3  Create  Tasking  Record 
Z4.3. 1  Select  Targets 
Z4.3.2  Select  Resources 
Z4.3.3  Assign  Resources  to  Case 
Z4.3.4  Create  Tasking  Record 
Z4.3.S  Read  Tasking  Record 
Z4.3.6  Update  Tasking  Record 
Z4.3J  Delete  Tasking  Record 
Z4.3.8  Fitter  Tasking  Records 
Z4.3.9  Display  Tasking  Record  UstRpt 
Z4.3. 10  Display  Tasking  Records  in  GIS 

2.4.4  Allocate  Resources 
Z4.4. 1  Select  Targets 
Z4.4.2  Select  Search  Areas 

Z4.4.3  Create  Resource  Alloc  Record 
Z4.4.4  Read  Resource  Alloc  Record 
Z4.4.6  Update  Resource  Alloc  Record 
Z4.4.6  Delete  Resource  Alloc  Record 
Z4.4.7  Filter  Resource  Alloc  Records 
Z4.4.8  Display  Resource  Alloc  UstRpt 
Z4.4.9  Display  Resource  Alloc  in  GIS 

2.5  Conduct  Operation 
2.5.1  Resource  Events 
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ZS,1.1  Create  Resource  Event 
ZS,  1.2  Read  Resource  Event 
ZS.  1.3  Update  Resource  Event 
ZS.  1.4  Delete  Resource  Event 
Z5.1.S  Evolve  Resource  Event 
ZS.  1.S  Filter  Resource  Events 
ZS.1.7  Display  Resource  Event  UstRpt 
ZS.  1.B  Display  Resource  Events  in  GIS 

2.5.2  SAR  Information 

2.5.2.1  GASP  Information 

2.5.2.1 .1  Search  Results 

ZS.Z1.1.1  Create  Search  Result  Record 
ZS.Z1.1.2  Read  Search  Result  Record 
ZS.Z  1. 1.3  Update  Search  Result  Record 
ZS.Z1.1.4  Delete  Search  Result  Record 
ZS.Z1.1.S  Filter  Search  Result  Record 
ZS.Z1. 1.S  Display  Search  Results  UstRpt 
ZS.Z1.1.7  Display  Search  Results  in  GIS 

2.5.2.1.2  Track  History 

ZS.Z1.Z1  Create  Track  History  Record 
ZS.Z1.Z2  Read  Track  History  Record 
ZS.Z1.Z3  Update  Track  History  Record 
ZS.Z  1.Z4  Delete  Track  History  Record 
ZS.Z  1.ZS  Filter  Track  History  Records 
ZS.Z  1.ZS  Display  Track  History  UstRpt 
2.S.Z1.Z7  Display  Track  Histories  In  GIS 

2.5.2.2  SAR  Summary  Information 
ZS.ZZ1  Create  SAR  Summary  Record 
ZS.ZZ2  Read  SAR  Summary  Record 
ZS.ZZ3  Update  SAR  Summary  Record 
ZS.ZZ4  Delete  SAR  Summary  Record 
ZS.ZZS  Filter  SAR  Summary  Records 
ZS.ZZ6  Display  SAR  Summary  Ust  Rpt 
ZS.ZZ7  Display  SAR  Summary  In  GIS 

2.5.3  LE  Information 

2.5.3. 1  Boarding  Information 
Z5.3.1.1  Create  Boarding  Record 
ZS.3.1.2  Read  Boarding  Record 
ZS.3. 1.3  Update  Boarding  Record 
ZS.3.1.4  Delete  Boarding  Record 
ZS.3.1.6  Finer  Boarding  Records 
ZS.3. 1.6  Display  Local  Boarding  Ust 
ZS.3.1.7  Display  Boardings  In  GIS 

2.5.3.2  Sighting  Information 
Z5.3.Z  1  Create  Sighting  Record 
ZS.3.Z2  Read  Sighting  Record 
ZS.3.Z3  Update  Sighting  Record 
ZS.3.Z4  Delete  Sighting  Record 
ZS.3.ZS  Finer  Sighting  Records 
ZS.3.Z6  Display  Local  Sighting  List 
ZS.3.Z7  Display  Local  Sightings  In  GIS 

2.5  3.3  Violation  Information 

ZS.3.3. 1  Create  Violation  Record 
ZS.3.Z2  Read  Violation  Record 
ZS.3.3.3  Update  VIolaUon  Record 
ZS.3.3.4  Delete  Violation  Record 
ZS.3.3.S  Finer  Violation  Records 
ZS.3.3.6  Display  Local  Violation  List 
ZS.3.3.7  Display  Loc  Violations  In  GIS 
2.5.3.4  Detection  Information 

ZS.3.4. 1  Create  Detection  Record 
ZS.3.4.2  Read  Detection  Record 
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Z5.3.4.3  Update  Detection  Record 
Z6.3.4.4  Delete  Detection  Record 
Z5.3.4.S  Filter  Detection  Records 
ZS.3,4.e  Display  Local  Detection  List 
ZS.3.4J  Display  Local  Detects  in  GIS 

2.5.3.5  Lookout  Information 

Z5.3.5. 1  Import  LEIS 11  Lookout  List 

25.3.5.2  Read  Lookout  List 

2513.5.3  Search  Lookout  List 

25.3.5.4  Filter  Lookout  List 

25.3.5.5  Display  Lookout  List 

25.3.5.6  Display  Lookout  List  In  GIS 

2.5.4  Chrono  Note 

25.4. 1  Create  Chrono  Notes 

25.4.2  Read  Chrono  Notes 

25.4.3  Update  Chrono  Notes 
ZS.4.4  Delete  Chrono  Notes 

25.4.5  Filter  Chrono  Notes 

ZS.4.6  Display  Chrono  Notes  List  Rpt 

2.5.5  OpNotes  (free  text  notes) 

25.5. 1  Create  OpNotes 

25.5.2  Read  OpNotes 

25.5.3  Update  OpNotes 
25.5w4  Delete  OpNotes 

2515.5  Filter  OpNotes 

25.5.6  Display  OpNotes  List  Rpt 

2.5.6  Crew  Events 

25.6.f  Create  Crew  Events 

25.6.2  Read  Crew  Everrts 

25.6.3  Update  Crew  Events 

25.6.4  Delete  Crew  Events 

25.6.5  Filter  Crew  Events 

25.6.6  Display  Crew  Event  Report 

2.6  Conclude  Operation 

2.6.1  Validation  Situation  Data 

26.  f .  1  Determine  Employ  Categories 
ZS,1.2  Determine  Resource  Events 

26. 1,3  Apply  Ruleset  1 
Z6,1,4  Apply  Ruleset  2 

26.15  Apply  Ruleset  3 

26.16  Apply  Ruleset  4 

26.17  Apply  Ruleset  6 
26.  f  .6  Apply  Ruleset  6 
26.19  Apply  Ruleset  7 
Z6.1,10  Apply  Ruleset  $ 

26.lt f  Build  Validation  Screen 
Zd.1,12  Commit  Validation  Changes 

2.7  Debrief  Ops  (see  Checklists) 

2.8  Document  Operation 

2.8.1  Resource  Employment  Tracking 
26.lt  Search  Resource  Employ  Data 
26. 1,2  Specify  Resource  Employ  Dates 
ZB,  1,3  Create  Resource  Employ  Record 
ZB,  1,4  Export  Resource  Employ  Data 

2.8.2  Populate  External  Systems 

2.8.2.1  Export  Board  Rpt  to  ProcCen 
ZB,Z1,1  Export  USCG  Unit  Data 
ZB,Z1,2  Export  Vessel  Data 
ZB,Z  1,3  Export  Person  Data 
ZB,Z1,4  Export  Boarding  Data 
ZB.Z  1,5  Export  Violation  Data 

2.8.2.2  Export  SABR  to  LEIS  II 
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ZB.2.Z1  Export  USCG  Unit  Data 
ZB.ZZ2  Export  Vassal  Data 
ZB,ZZ3  Export  Parson  Data 
ZB.ZZ4  Export  Sighting  Data 
ZB.ZZS  Export  Boarding  Data 
ZB.ZZ6  Export  Violation  Data 
ZB.ZZ7  Export  Dataedon  Data 

2. Q.2.3  Export  Data  to  SARMIS 

ZB.ZZ1  Export  SARMIS  Record 
ZB.Z3.2  Export  SARMIS  "S"  Record 
ZB.ZZ3  Export  SARMIS  "C"  Record 
ZB.ZZ4  Export  SARMIS  *0*'  Record 

2.8.2.4  Export  Qtrly  Aops  Rpt  to  Aops 
ZB.Z4.1  Saarch  USCG  Unit  Data 
ZB.Z4.2  Saarch  USCG  Rasourca  Data 
ZB.Z4.3  Tally  Rasourca  Evant  Durations 
ZB.Z4.4  Create  Employmant  Racord 
ZB.Z4,6  Create  Resource  Racord 
ZB,Z4.B  Create  Export  Disk  Flla 

ZB.ZS  Create  Draft  SITREP 
2.9  Time  Zone  Conversion  Algorithm 
Z9.1  Local  to  Zulu  bafora  DB  commit 
Z9.2  Zulu  to  Local  bafora  display 

3  Manage  Communications 

3.1  Shore  Comms  Module 

3.1 .1  Shore  Comms  Transmit  Module 

3.1.1.1  Ratrlava  Data  tor  Datagram 
X1.L2  Writa  data  to  Datagram 
3.1.1.3  Comprass  Datagram 
X1.1.4  Encrypt  Datagram 

3. 1. 1.5  Transmit  Datagram  using  EDAC 

3.1 .2  Shore  Comms  Receive  Module 
X1.Z1  Racahra  Datagram 

3.1. Z2  Dacrypt  Datagram 

3.1. Z3  Decompress  Datagram 

3. 1. Z4  Parse  data  out  of  Datagram 

3.1. ZS  Sand  data  to  updataprocass 

3.2  Boat  Comms  Module 

3.2. 1  Boat  Comms  T ransmit  Module 

3, Z  1.1  Ratrlava  Data  for  Datagram 
XZ1.2  Wrtta  data  to  Datagram 
3.Z1.3  Comprass  Datagram 

3.Z  1.4  Encrypt  Datagram 

XZ  1.S  Transmit  Datagram  using  EDAC 

3.2.2  Boat  Comms  Receive  Module 
XZZ1  Racafva  Datagram 
3.ZZ2  Dacrypt  Datagram 
XZZ3  Dacomprass  Datagram 
3.ZZ4  Parsa  Data  out  of  Datagram 
3.ZZS  Sand  Data  to  updataprocass 

3.3  Aircraft  Comms  Module 

3.3. 1  Aircraft  Comms  Transmit  Module 
X3.1.1  Ratrlava  Data  tor  Datagram 
X3.1.2  Writa  data  to  Datagram 
X3.1.3  Comprass  Datagram 
XX1.4  Encrypt  Datagram 

X3.1.S  Transmit  Datagram  using  EDAC 

3.3.2  Aircraft  Comms  Receive  Module 
3.3.2L  1  Racalva  Datagram 

3.3. Z2  Dacrypt  Datagram 

3.3. Z3  Dacomprass  Datagram 
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3.3. Z4  Parse  Data  out  of  Datagram 

3.3. ZS  Send  Data  to  update  process 

4  Manage  System 

4.1  Manage  User  Accounts 

4.1.1  Create  User  Account 

4. 1.2  Read  User  Account 

4.1.3  Update  User  Account 

4. 1.4  Delete  User  Account 

4.2  Control  Access 

4.Z  1  Get  Username  and  Password 
4.Z2  Check  Username  and  Password 
4.Z3  Start  Application 
4.Z4  Redisplay  Logon  Screen 
4.ZS  Write  Logon  Attempt  to  Aud  Log 

4.3  Set  System  Defaults 

4.3.1  Set  Default  OPFAC  and  Resource 

4.3.2  Set  Default  OPCON 

4.3.3  Set  Time  Zone 

4.3.4  Set  Defyult  Chart 

5  On-line  Help 

5.1  Help  Screens 

5.2  Help  System  Indexing 

5.3  Help  System  Topic  Assignments 

5.4  Help  System  Example  Data  Sets 

5.5  Help  System  Hypertext  Links 

5.6  Help  System  Context  IDs 

5.7  Help  System  Status  Bars 
S.B  Help  System  Tool  Tips 
5.9  Help  S^tem  Balloon  Help 

6  VTS20CX)  Interface  Placeholder 

7  MSN  Interface  Placeholder 

8  Multi-Level  Security  Placehold 
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Cost  estimates  are  considered  Procurement  Sensitive  Information,  release  of  which  could  detract 
from  full  and  open  competition  in  future  acquisitions  involving  OIS.  Therefore,  this  appendix  has 
been  deleted  from  the  publicly  available  version  of  this  report. 
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APPENDIX  E:  COAST  GUARD  OPERATIONAL 
COMMUNICATIONS  COST  MODEL 


Cost  estimates  are  considered  Procurement  Sensitive  Information,  release  of  which  could  detract 
from  full  and  open  competition  in  future  acquisitions  involving  OIS.  Therefore,  this  appendix  has 
been  deleted  from  the  publicly  available  version  of  this  report. 
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APPENDIX  F:  BENEFITS  ANALYSIS  FOR  OIS  PHASES  I  AND 

II 

This  appendix  is  included  in  order  to  extrapolate  the  quantifiable  benefits  measured  during  the 
Group/Station  OIS  Testbed  to  Phase  II.  The  analysis  is  based  on  the  Functional  Decomposition 
in  Appendix  F,  which  is  summarized  in  Table  13.  The  primary  functional  difference  between 
Phase  I  and  Phase  n  is  the  additional  integration  of  Computer  Aided  Search  Planning  System 
(CASP).  The  primary  resource  difference  is  the  addition  of  Cutters,  Aircraft,  District  and  Area 
command  centers.  This  would  involve  developing  an  additional  mobile  subsystem,  optimized  for 
aircraft  use.  However,  higher  level  command  centers  would  use  the  same  command  center  system 
as  developed  for  Group/Station  OIS.  Cutters  would  also  use  the  same  system  as  shoreside 
command  centers.  The  Benefits  Analysis  has  been  prepared  in  accordance  with  guidelines  in  the 
Coast  Guard’s  draft  Benefit-Cost  Analysis  Manual  for  the  Acquisition  of  Federal  Information 
Processing  (FIP)  Resources,  COMDTINST  M71 10. 1 . 


Table  13:  Major  OIS  Phase  I  and  II  functions. 


Shoreside  Subsystem 

Aircraft  Subsystem 

Utility  Boat  Subsystem 

i  Geographic  Information  System  to  i 
integrate  operational  information 

Electronic  Chart  System  to 
improve  navigational  accuracy 

Data  entry,  including  source  data 

1  capture  (requires  fast  response  for 
i  use  during  ops)  . j 

Source  data  capture,  during  SAR 
and  sightings,  via  pen-based 
computer  ; 

Source  data  capture,  during  SAR 
and  boardings,  via  pen-based 
computer 

1  Data  distribution,  allowing  all 

1  units  access  to  shared  case 
j  information,  and  resolving 
!  conflicts  between  updates 

Data  distribution 

Data  distribution 

integrated  Search  Planning 
(CASP) 

Integrated  search  pattern  receipt 
from  command  center,  execution, 
and  tracking 

Integrated  search  pattern  receipt 
from  command  center,  execution, 
and  tracking 

i  Electronic  checklists 

1  Electronic  checklists  | 

i  Electronic  checklists 

1  Resource  and  facility  tracking  via 

I  CIS 

1  Remote  Dependent  Surveillance 

1  System  (RDSS)  for  ops  and 

1  position  reporting 

1  Remote  Dependent  Surveillance 

I  System  (RDSS)  for  ops  and 
i  position  reporting  | 

1  viidation  to  verify  completeness 

1  and  accuracy  for  external  systems. 

1  Validation 

i  Validation  i 

i  Operational  reports  consolidation 

1  and  export  to  external  systems 

i  Automatic  Report  Generation 

i  Automatic  Report  Generation 

j  Online  access  to  LEIS  11 
i  information 

i  Online  access  to  LEIS  II 
j  information 

j  Online  access  to  LEIS  II 
i  information 

i  Electronic  tasking  to  resources 

i  Electronic  tasking  and  status 
i  reporting 

j  Electronic  tasking  and  status 
j  reporting 

i  integrated  Decisions  Aids 

j  Integrated  Decisions  Aids,  such  as 

I  regulation  references  on-line 

I  Integrated  Decisions  Aids,  such  as  \ 
j  regulation  references  on-line 
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Table  14  sununarizes  the  annual  and  life  cycle  benefits  attributable  to  the  Operational  Information 
System,  Phases  I  and  11.  As  with  the  Phase  I  Benefits  Analysis  in  Chapter  6,  this  table  includes 
only  benefits  which  could  be  measured  based  on  the  research  done  to  date.  It  does  not  project 
benefits  which  could  be  derived  from  business  process  reengineering  enabled  by  OIS.  The  first  set 
of  benefits  are  those  which  are  directly  quantifiable,  and  capturable  within  the  Coast  Guard 
budget  as  either  direct  cost  savings  or  cost  avoidances.  The  second  set  of  benefits  are  quantified, 
but  cannot  be  captured  within  the  Coast  Guard  budget.  For  instance,  reports  reduction  will  save 
our  field  personnel  from  working  overtime.  However,  since  military  personnel  are  not 
compensated  for  overtime  work,  this  does  not  present  a  benefit  that  can  be  captured  in  the 
budget.  It  is  likely  to  produce  long-term  benefits  such  as  better  retention  because  of  improved 
working  conditions,  reduced  health  care  cost  because  of  lowered  stress,  and  similar  work-life 

concerns 


Table  14: 


OIS  Phase  I  and  II  benefit  summary,  in  millions  of  dollars. 


Benefit 

Tyne  Benefit  Descriotion 

One-Time 

Benefit 

($M) 

Annual 

Benefit 

($M) 

Total  Life 
Cycle 
Benefit 
($M) 

MonAti7;)hle  Benefits  (Direct  Cost  Avoidance  or  Savings) 

Avoidance  of  accidental  collisions  and  groundings 

$2.0 

$20.0 

Subtotal,  Monetizable  Benefits  ($M) 

$0.0 

$2.6 

$20.0 

Non-Monetizable  Benefits  (Indirect  Cost  Avoidance  or  Benefits  to  Society  in  General) 

Report  Reduction 

Improved  Search  Accuracy 

$1.1 

$13.4 

$11.0 

$133.6 

Subtotal,  Non-Monetizable  Benefits  ($M) 

$0.0 

$14.5 

$144.6 

Total  Benefits  ($M) 

$0.0 

$16.5 

$164.6 

Reports  Reduction 

The  Benefits  Analysis  in  Chapter  6  estimates  savings  from  reports  reductions  for  Groups  and 
Stations.  In  Table  15,  these  savings  are  extrapolated  to  all  SAR  and  LE  operating  units.  The 
table  makes  the  same  underlying  assumptions  as  the  earlier  analysis. 
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Table  15:  Annual  benefit  of  operational  reports  reduction. 


Minutes 

saved 

per 

Reports 

Hours 

saved 

Labor 

Benefit, 
dollars  per 

Report  Type 

report 

per  year 

per  year 

Rate 

year 

SARMIS  entries 

7 

65,000 

7,800 

17 

$132,600 

SEER  Messages  (Boardings) 

7 

25,000 

2,708 

24 

$65,000 

SEER  Messages  (Sightings) 

2 

90,000 

3,000 

24 

$72,000 

Boarding  Report  (CG  4100) 

2 

25,000 

833 

24 

$20,000 

SITREPS  (10%  of  SAR  cases) 

30 

6,500 

3,250 

24 

$78,000 

Distress  checkoff  sheet 

0 

- 

17 

$0 

POLREPS 

30 

5,000 

2,500 

24 

$60,000 

Abstract  of  Operations  Rpt 

60 

8,000 

8,000 

24 

$192,000 

SAR  Case  Folder 

3 

65,000 

3,250 

17 

$55,250 

MLE  Weekly  Feeder  Reports 

10 

26,000 

4,333 

24 

$104,000 

Abbreviated  Radio  Log 

2 

65,000 

2,167 

17 

$36,833 

Chrono  log 

0 

- 

17 

$0 

Unit  Underway  Hours  log 

1 

100,000 

1,667 

17 

$28,333 

Weather  log 

0 

- 

17 

$0 

Training  log 

2 

400,000 

13,333 

17 

$226,667 

Auxiliary  Orders  log 

0 

- 

17 

$0 

SEER  log 

1 

115,000 

1,917 

17 

$32,583 

Totals 

54,758 

$1,103,267 

Improved  Search  Precision 

Better  resource  allocation  and  tracking  improve  pilot  confidence,  so  allows  more  time  searching 
for  surface  target  and  less  time  scanning  surrounding  airspace  for  conflicting  aircraft. 

The  success  of  search  efforts  depends,  in  part,  on  the  navigational  precision  of  Search  &  Rescue 
Units  (SRUs),  particularly  aircraft  as  they  execute  search  patterns.  For  a  variety  of  reasons,  which 
are  explained  in  following  paragraphs,  the  performance  of  CG  resources  in  search  operations  is 
described  (from  a  strictly  theoretical  standpoint)  as  random.  These  random  searches  are 
expensive  and  sometimes  fhiitless.  By  improving  navigational  precision,  the  Coast  Guard  could 
make  dramatic  improvements  in  search  capabilities,  and  lower  costs.  Even  more  important,  we 
would  expect  to  save  more  lives  by  (a)  locating  victims  instead  of  not  locating  them,  and  (b) 
locating  them  sooner,  before  hypothermia  and  exposure  have  set  in. 

The  Coast  Guard’s  Computer  Aided  Search  Planning  system  (CASP)  allows  command  center 
watchstanders  to  generate  search  patterns  automatically.  However,  these  patterns  must  be 
decomposed  into  descriptive  text  and  transmitted  to  Search  and  Rescue  Units  (SRUs)  by  voice  or 
text-based  methods,  then  re-plotted  or  entered  in  SRU  navigation  systems.  Finally,  the  SRU 
commander  must  manually  navigate  the  craft  through  the  search  pattern  and  report  results  back  to 
the  command  center  for  effectiveness  calculations.  Using  OIS  to  integrate  CASP  into  the  actual 
search  execution  instead  of  stopping  at  the  planning  stage  would  create  significant  improvements 
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in  search  pcrforrnEiicc.  It  would  eIso  niEkc  even  more  substEntiEl  improvements  in  EnElyzing 
searches  that  did  not  locate  the  targets,  and  in  planning  subsequent  searches. 

The  basis  for  the  following  discussion  is  work  done  over  the  last  twenty  years  by  the  Coast 
Guard’s  Research  and  Development  Center,  both  in  search  effectiveness  experiments  and  in 
CASP  design  and  upgrades.  These,  in  turn,  are  based  largely  on  the  search  theories  developed 
during  World  War  II  by  B.  O.  Koopman.  The  resultant  search  planning  guidelines  appear  in  the 
National  SAR  Manual.  Koopman  described  the  search  performance  of  visual  detection  with  his 
"inverse  cube  law,”  which  is  based  on  the  following  conditions. 

1  The  primary  sensor  is  the  human  eye  (visual  search). 

2.  The  primary  sensor  platform  is  a  patrol  aircraft. 

3 .  The  search  objects  are  large  warships  underway. 

4.  The  search  object  is  contained  in  the  search  area. 

5.  The  search  legs  are  exactly  parallel  relative  to  the  search  object  (whether 
moving  or  stationary). 

6.  Initial  detection  is  by  sighting  the  vessel's  wake. 

7.  The  instantaneous  probability  of  detection  is  inversely  proportional  to  the  solid 
angle  subtended  at  the  observer's  eye  by  the  vessel's  wake. 

The  last  assumption  leads,  mathematically,  to  the  equivalent  assumption  that  the  instantaneous 
probability  of  detection  is  inversely  proportional  to  the  cube  of  the  target's  range  from  the 
observer.  Hence,  we  say  this  visual  detection  model  describes  an  "inverse  cube  law"  sensor. 

Given  the  characteristics  of  a  sensor,  the  next  obvious  task  is  to  determine  how  to  best  employ 
that  sensor.  In  other  words,  the  best  tactics  for  using  the  sensor  need  to  be  determined. 
Koopman  found  that  for  a  uniform  target  probability  distribution  within  some  area,  any  sensor 
which  has  a  "peaked"  lateral  range  curve  (LRC)  is  best  employed  by  covering  the  area  with 
equally  spaced  parallel  tracks.  A  lateral  range  curve  describes  the  probability  of  detection  as  a 
function  of  range  perpendicular  to  the  sensor's  track  after  one  complete  "fly-by"  of  the  search 
object.  The  inverse  cube  law  produces  a  veiy  "peaked"  lateral  range  curve.  That  is,  the 
probability  of  detection  very  close  to  the  sensor's  track  is  nearly  100%  and  then  decreases  rapidly 
as  lateral  range  increases.  It  is  important  to  note  that  for  moving  targets,  it  is  necessary  to  adjust 
the  search  legs  keep  them  parallel  relative  to  the  target  in  order  to  realize  the  benefits  of  parallel 

path  searching. 

The  benefits  of  organized,  parallel  path  searching  can  be  significant.  To  establish  a  basis  for 
comparisons,  we  need  to  look  at  two  other  theoretical  curves  of  Probability  of  Detection  (POD) 
vs.  Coverage  Factor  (CF).  The  first  is  for  a  "perfect"  sensor.  Such  a  sensor  is  said  to  obey  a 
definite  range  law  because  within  some  specific  range,  detection  is  guaranteed  while  outside  that 
range  no  detection  ever  occurs.  For  such  a  "perfect"  sensor,  POD  equals  Coverage  Factor  for 
Coverage  Factors  of  1 .0  or  less.  Above  1 .0,  there  is  no  additional  benefit  because  POD  is  already 
at  100%.  The  other  POD  vs.  Coverage  Factor  curve  that  needs  to  be  considered  is  the  so  called 
"random  search  curve".  This  curve  has  a  specific  mathematical  definition  (as  do  the  other  two), 
but  random  search  can  be  thought  of  as  an  aircraft  flying  a  series  of  short  random  legs  but  staying 
within  the  search  area. 


February  1995 


F-4 


USCG  Operational  Info  System 


Group/Station  01 S  Testbed  Evaluation  Report 


The  following  definitions  apply  to  further  discussion: 

♦  Sweep  Width:  the  area  under  the  lateral  range  curve  (miles) 

♦  Search  Effort:  the  product  of  Sweep  Width  and  Trackline  Miles  traversed  by 
the  sensor  (square  miles) 

♦  Coverage  Factor:  the  ratio  of  Search  Effort  to  the  Area  being  searched 
(computing  Coverage  Factor  as  the  ratio  of  Sweep  Width  to  Trackspacing  is 
just  a  convenient  mathematical  shortcut  valid  only  for  parallel  path  search 
patterns) 

♦  POD:  Probability  Of  Detection  -  probability  of  detecting  the  target,  given  that 
it  is  in  the  area  being  searched 

♦  POA:  Probability  Of  the  target  being  in  the  Area  -  also  sometimes  called  POC 
(Probability  Of  Containment). 

♦  POS:  Probability  Of  Success  -  the  probability  of  finding  the  target  in  the  area 
being  searched.  POS  is  the  product  of  POD  and  POA  (POS  =  POD  x  POA) 

At  coverage  factor  1.0,  a  definite  range  law  sensor  produces  a  POD  of  100%  for  a  perfect  (zero 
navigational  error)  parallel  path  search;  an  inverse  cube  law  sensor  produces  a  POD  of  78%  under 
the  same  conditions;  but  a  random  search  produces  a  POD  of  only  about  63%.  Furthermore, 
random  search  POD  depends  only  on  Coverage  Factor.  Either  a  definite  range  law  sensor,  or  an 
inverse  cube  law  sensor,  or  any  other  sensor,  if  employed  in  a  random  search  pattern,  will  produce 
the  same  63%  POD  for  a  Coverage  Factor  of  1 .0. 

To  understand  the  true  benefit  of  organized,  parallel  path  searching,  it  is  necessary  to  compare  the 
amounts  of  effort  required  to  achieve  the  same  results  using  random  search.  To  achieve  a  78% 
POD  using  random  search,  a  Coverage  Factor  of  1.5  is  required.  In  other  words,  it  takes  50% 
more  effort  to  achieve  the  same  level  of  search  effectiveness  with  an  inverse  cube  law  sensor  if  it 
is  employed  randomly  rather  than  in  parallel  paths  relative  to  the  search  object.  The  situation  is 
even  more  pronounced  with  a  "perfect"  definite  range  law  sensor  -  random  searching  requires 
nearly  twice  the  effort  to  achieve  78%  POD  as  compared  to  parallel  path  searching. 

So  far  we  have  been  comparing  extremes  of  search  execution:  perfectly  executed  parallel  paths 
versus  complete  randomness.  A  key  question  in  moving  from  the  theoretical  to  the  practical  is, 
"How  rapidly  does  the  POD  deteriorate  toward  the  random  search  curve  as  a  function  of 
deterioration  in  parallel  path  search  pattern  execution?" 

There  are  several  ways  in  which  a  parallel  path  search  pattern  can  be  improperly  executed.  The 
first  we  will  consider  involves  relatively  small  navigational  error.  In  this  case,  the  search  craft 
begins  the  search  correctly,  within  the  search  craft's  normal  navigational  error  of  the  commence 
search  point  (CSP)  and  stays  within  that  distance  of  its  intended  trackline  throughout  the  search. 
We  may  simulate  the  effects  of  such  error,  or  search  craft  position  uncertainty,  by  considering  the 
cross-track  error  along  the  search  legs.  If  the  cross-track  error  is  normally  distributed,  then  we 
may  compute  the  convolution  of  the  "normal"  function  with  the  lateral  range  curve  to  get  an 
expected,  or  average,  lateral  range  curve  for  the  given  cross-track  error.  The  expected  POD  vs. 
Coverage  Factor  curve  can  then  be  computed  for  this  expected  LRC.  Such  expected  LRCs  are 
less  peaked  than  the  original  LRC  of  the  sensor  itself  even  though  the  areas  (sweepwidths)  under 
the  two  curves  are  identical.  If  the  position  of  the  sensor  is  uncertain  relative  to  the  intended 
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track,  then  the  POD  for  a  target  on  the  intended  track  is  likewise  uncertain  and,  on  average  over 
many  trials,  lower.  Likewise,  the  POD  for  targets  a  significant  distance  off  the  intended  track  will 
be  raised  somewhat.  As  the  shape  of  the  lateral  range  curve  becomes  more  and  more  flat  with  a 
more  nearly  constant  (but  low)  expected  POD  over  a  large  range  (i.e.  the  opposite  of  peaked),  the 
more  closely  the  POD  vs.  Coverage  Factor  curve  approaches  that  of  random  search.  If  the 
sensor's  lateral  range  curve  is  low  and  nearly  flat,  then  where  it  is  placed  becomes  unimportant, 
and  hence  there  is  little  or  no  benefit  to  parallel  path  searching  over  random  searching  -  both  will 
produce  the  random  search  curve.  If  navigational  error  is  large  enough  to  reduce  a  sensor's 
peaked  LRC  down  to  one  that  is  effectively  low  and  flat,  the  same  result  -  random  search  PODs  - 

will  occur. 

For  normally  distributed  cross-track  errors,  significant  reductions  in  POD  occur  when  the 
standard  deviation  of  the  crosstrack  error  is  equal  to  the  sweepwidth.  By  the  time  the  standard 
deviation  approaches  two  sweepwidths,  the  POD  is  nearly  down  to  random  search  values.  Since 
the  sweepwidths  for  SAR  targets  are  typically  smaU,  accurate  navigation  and  search  pattern 
execution  are  essential. 

Other  even  more  dramatic  effects  on  POD/POS  can  be  introduced  by  navigational  error.  The 
most  obvious  is  failing  to  search  the  correct  area  but  searching  a  different  one  instead.  This  is 
usually  the  result  of  human,  rather  than  equipment,  error.  A  less  obvious  type  of  error  is  that 
introduced  by  unintended  relative  motion  between  the  target  and  the  sensor. 

Unintended  relative  motion  can  be  introduced  in  two  ways,  which  may  both  be  present  at  the 
same  time.  First,  until  recently,  SAR  search  planning  doctrine  did  not  consider  the  effects  of 
target  motion  even  though  most  maritime  SAR  targets  are  adrift  and  therefore  moving. 
Apparently  it  was  believed  that  typical  rates  of  drift  were  so  small  compared  to  the  speed  of  the 
search  craft,  especially  aircraft,  that  target  motion  was  insignificant.  The  correct  values  to 
compare,  however,  are  the  target's  drift  rate  Avith  the  search  craft's  rate  of  creep  through  a  parallel 
path  search.  Consider  a  target  in  the  Straits  of  Florida  moving  north  at  four  knots.  An  aircraft 
flying  across  the  strait  (approximately  60  nautical  miles)  at  120  knots  and  creeping  north  on  a  two 
mile  trackspace  would  be  moving  north  at  exactly  four  knots.  Thus,  the  distance  between  the 
search  craft  and  the  target  would  remain  constant  throughout  the  search!  The  POD,  therefore, 
would  be  very  high  if  the  target  was  on  or  near  the  search  craft's  initial  search  leg  and  very  low 
otherwise.  Thus,  the  POD  for  targets  in  the  vast  majority  of  the  search  area  at  commence  search 
time  would  be  very  low,  driving  the  POS  for  the  intended  search  area  down  to  a  correspondingly 
low  value.  For  ten  search  legs  (a  five  hour  search)  and  a  coverage  factor  of  1.0,  the  POD  would 
be  on  the  order  of  10  percent  because  all  the  search  effort  was  concentrated  in  roughly  10  percent 
of  the  intended  search  area  relative  to  the  target.  In  this  case,  a  perfectly  executed  parallel  path 
search  would  produce  results  well  below  the  random  search  curve. 

A  first-order  correction  to  this  type  of  problem  is  to  orient  the  search  legs  in  the  direction  of 
target  motion  to  minimize  its  impact  on  the  trackspacing  and  parallelism  of  the  search  legs  and 
area  covered  relative  to  the  target's  predicted  motion.  A  refinement  is  to  skew  the  normally 
rectangular  search  areas  into  parallelograms  to  compensate  for  target  motion  during  the  search. 
Another  technique  is  to  use  a  barrier  search  pattern  with  search  legs  roughly  perpendicular  to  the 
direction  of  drift  which  compensate  for  predicted  target  motion.  This  latter  technique  is  not 
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recommended  due  to  the  sensitivity  of  the  actual  trackspacing  and  parallelism  of  the  search  legs, 
the  area  covered,  and  hence  the  POD,  to  variations  and  uncertainties  in  the  target's  motion. 

The  second  way  unintended  relative  motion  between  the  sensor  and  the  target  can  be  introduced 
is  through  navigational  error.  If  the  search  craft  fails  to  correctly  compensate  for  set  and  drift  and 
leeway  (vessels)  or  cross  winds  (aircraft),  then  systematic  pattern  errors,  like  those  introduced  by 
a  failure  to  compensate  for  target  motion,  will  be  introduced  with  the  same  devastating  effects  on 
POD. 

Given  the  numerous  sources  of  search  pattern  error  (general  navigational  error,  diverting  to 
investigate  sightings,  systematic/cumulative  errors,  etc.)  when  looking  for  targets  whose  motion 
can  be  predicted  with  only  limited  accuracy,  a  strong  case  can  be  made  for  discarding  our  present 
inverse-cube-law-based  POD  vs.  Coverage  Factor  curve  in  favor  of  the  random  search  curve.  In 
fact,  given  the  devastating  systematic  pattern  errors  discussed  above,  the  random  search  curve 
may  well  be  the  best  we  have  any  right  to  expect.  To  justify  using  any  more  optimistic  POD  vs. 
Coverage  Factor  curve,  the  Coast  Guard  needs  more  accurate  navigational  techniques  and 
computer  assistance  which  can  aid  the  search  planner  in  developing,  and  the  SRU  in  accurately 
executing,  search  plans  for  moving  targets.  For  PIW  searches,  this  might  even  require 
development  and  deployment  of  navigational  DMBs  which  an  SRU  would  use  as  navigational  aids 
to  execute  a  parallel  path  search  relative  to  the  moving  water,  rather  than  relative  to  the  fixed 
bottom.  In  fact,  a  small  boat  in  a  tidal  region  navigating  by  DR  without  regard  to  set  and  drift  is 
probably  doing  a  better  search  for  a  PIW  than  one  using  very  accurate  navigational  aids  to 
precisely  execute  a  parallel  path  search  relative  to  the  ground. 

For  parallel  path  searches  using  an  inverse  cube  law  sensor,  the  probability  of  detection  can  be 
calculated  using 


Equation  1:  POD  =  erf  (0.8862  x  CF) 

where  CF  is  equal  to  the  coverage  factor  (track  space  divided  by  track  spacing),  0.8862  is  equal 
to  the  square  root  of  pi  divided  by  2,  and  erf  is  the  error  function  which  can  be  found  in  the 
probability  tables  of  most  mathematical  handbooks. 

For  random  searching,  the  POD  can  be  calculated  using  the  following  formula: 

Equation  2:  POD  =  1  -  e-CF 

The  problem  with  these  laws  is  that  they  no  longer  apply  when  the  SAR  target  drifts  out  of  the 
search  area.  For  the  purposes  of  discussing  improvements  to  search  performance  through  search 
craft  navigational  precision,  however,  the  POA  is  not  material.  The  discussion  must  in  fact 
assume  that  the  target  is  always  in  the  intended  search  area,  i.e.,  POA  =  100%. 

Table  16  summarizes  the  benefits  of  using  improved  navigational  precision.  The  table  shows  that 
improved  navigation  could  increase  search  effectiveness  by  24%  without  expending  additional 
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resources,  The  table  was  based  the  1990  Abstract  of  Operations  for  aircraft,  and  from 
COMDTINST  73 10.  IE  (standard  rates). 


Table  16:  Annual  benefit  due  to  increased  SRU  navigational  precision. 


USCG 

Operating 

Platform 

Annual 

SAR  Sortie  Annual 

Hrs  Search  Hrs 

Operating  Annual  Search 
Cost  per  Dollars, 

hour  Millions 

Benefit  due 
Improved 
Accuracy, 
Millions 

HC-130H 

3,830 

1,163 

4,081 

$4.7 

$2.4 

HU-25 

3,846 

999 

3,785 

$3.8 

$1.9 

HH-60J 

4,530 

1,588 

3,660 

$5.8 

$2.9 

HH-65A 

9,946 

2,823 

3,638 

$10.3 

$5.1 

WAGB 

3,140 

$0.0 

$0.0 

WHEC 

497 

24 

2,521 

$0.1 

$0.0 

WMEC 

2,786 

247 

1,427 

$0.4 

$0.2 

WLB 

995 

1,034 

$0.0 

$0.0 

WLM 

782 

$0.0 

$0.0 

WTGB 

1,381 

887 

$0.0 

$0.0 

WYTL 

296 

$0.0 

$0.0 

WPB 

25,114 

493 

$0.0 

$0.0 

MLB 

9,030 

579 

403 

$0.2 

$0.1 

UTB 

36,333 

3,178 

299 

$1.0 

$0.5 

RHIB 

6,638 

664 

223 

$0.1 

$0.1 

UTL 

13,362 

1,229 

290 

$0.4 

$0.2 

BU/BUSL 

381 

$0.0 

$0.0 

$26.7 

$13.4 

Each  resource  class  spends  a  substantial  amount  of  time  per  year  searching,  as  indicated  in  the 
third  column  of  the  table.  Multiplying  the  third  column  times  the  fourth  column  gives  the  annual 
cost  of  searching  for  each  resource  class.  As  explained  in  the  preceding  paragraphs,  this 
searching  is  theoretically  random,  where  POD  =  63%  at  CF  =  1.  Then  the  total  annual  cost  of 
searches  is  $68. 9M. 

In  order  to  increase  the  level  of  effort  so  that  the  POD  would  equal  78%,  under  random  search 
conditions  we  would  have  to  increase  the  coverage  factor  to  CF  =  1.5.  This  would  require  a  50% 
increase  in  operating  costs,  or  $34. 5M.  If  we  could  improve  our  search  performance  to  that 
which  is  described  by  the  inverse  cube  law,  we  would  be  able  to  achieve  a  POD  of  78%  without 
having  to  spend  the  additional  34.5  million  dollars. 

The  preceding  analysis  assumed  100%  probability  of  containment  of  the  target  in  the  search  area 
(POA  =  100%).  In  actuality  this  is  not  the  case,  since  SRUs  sometimes  stray  into  search  areas 
where  the  POA  is  low  or  even  zero.  They  have  even  been  known  to  miss  the  intended  search  area 
altogether.  These  problems  all  stem  from  navigational  error.  Since  probability  of  success  (POS)  is 
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equal  to  POD  times  POA,  POS  degrades  rapidly  as  POA  is  reduced.  This  makes  the  actual 
benefits  of  improved  precision  even  greater. 
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APPENDIX  G:  SOFTWARE  DEVELOPMENT  COST  ESTIMATE 
DETAILS  FROM  CHECKPOINT,  OIS  PHASE  I 


Cost  estimates  are  considered  Procurement  Sensitive  Information,  release  of  which  could  detract 
from  full  and  open  competition  in  future  acquisitions  involving  OIS.  Therefore,  this  appendix  has 
been  deleted  from  the  publicly  available  version  of  this  report. 
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APPENDIX  H:  SOFTWARE  DEVELOPMENT  COST  ESTIMATE 
DETAILS  FROM  CHECKPOINT,  OIS  PHASE  H 


Cost  estimates  are  considered  Procurement  Sensitive  Information,  release  of  which  could  detract 
from  full  and  open  competition  in  future  acquisitions  involving  OIS.  Therefore,  this  appendix  has 
been  deleted  from  the  publicly  available  version  of  this  report. 
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